Avoid using fixed versions in composer.json

ad chrfritsch:
>We have to use fixed versions for projects where we ship some patches

I see, still I don't think this works out. When I have a project based on thunder, I should be able to upgrade to next version. If the patch does not apply any more, well I did the upgrade and I have to take care of it. But with the current situation, composer just denies my to change the version at all! Even if there is a new stable release which has all patches added, there is no way to use it.

However, I do not know whether it's even possible to change the patches in the project as they are part of the install profile as well? If composer-patches does not allow that, I'd recommend dropping patch files and using forks instead of patches. Forks are just special versions which can override as needed on the project level.
If of interested, you can find an example on how to do that in http://www.slideshare.net/nuppla/efficient-development-workflows-with-co....

"drupal/paragraphs": "1.x-dev as 1.0"

Right that works. It will a bit confusing when you are mapping future releases like 1.3 to 1.0 though.

We would have to rename drupal/paragraphs to burdamagazinorg/paragraphs and register that fork on pacvkagegist, but then you would not be able to update at all, or am I missing something?

That works fine without renaming things. E.g. you can fork a package like that:

"require": {
    "samson/youtrack": "dev-fix-branch as 2.0.0"
},
"repositories": [
  {
    "type": "vcs",
    "url": "https://github.com/fago/youtrack"
  }
],

If the package has no composer.json committed like most drupal modules, you'd have to add it via type "package" to the repositories instead.

True, I agree this is not a good solution either then. Looks like forking the thunder-distribution is the only solution to make overriding patches possible then. Maybe best composer-patches would be improved to allow re-defining patches in the root composer project file (in my tests this did not work out).

Still, this does not really require to depend on fixed versions, does it? If I'd update the version to another release, it would just try to apply the same patches again, what seems fine to me. If the patch does not apply, composer-patches will have to fail and show an error anyway.

Not quiet true, composer will show a warning, but it will not fail.

hm, I see. That's an issue with composer patches then. If it fails to do its work, it should fail. Any possibility of ending up with the wrong code would be an issue obviously. So I guess this means we'd need to improve composer-patches before being able to do that.

We try to deliver the distribution without those kind of problems, that is why we decided to provide patches for fixed versions only. But we will think about changing this policy.

I see - that's great. But then, for building projects on top of it should be possible to upgrade modules, add patches etc., such that you can solve any possible upcoming issues in your project.