Problem/Motivation
Ideally the root farmOS project composer.json file could remove the "minimum-stability": "dev" line, and fall back on the default (stable): https://getcomposer.org/doc/04-schema.md#minimum-stability
Then, it would be up to downstream maintainers of their projects to decide if they need additional non-stable dependencies, and could add that line themselves. Meanwhile farmOS could have a policy of only allowing "stable" dependencies.
Proposed resolution
We have a few dependencies right now that still require the "minimum-stability": "dev" line. Let's identify them and figure out next steps.
Remaining tasks
-
Identify non-stable dependencies.
- config_update #3384689: Provide stable 2.0 release
csv_serialization#3196564: Stable 2.0 releaseentity_reference_integrity8.x-1.0entity_reference_validators:2.0.0farmOS-mapfractionhttps://www.drupal.org/project/fraction/releases/2.0.0gin5.0.12- inline_entity_form #2576445: Inline Entity Form stable release plan
jsonapi_schema8.x-1.0log#3151227: Drupal 9 releaseviews_geojson#3207257: Requesting 8.x-1.1 release
- ...
User interface changes
None.
API changes
None.
Data model changes
None.
Comments
Comment #2
m.stentaAdding "beta blocker" tag.
Comment #3
m.stentaWe will be adding the Views GeoJSON module, but currently it has some commits in the dev branch that we need. See #3207257: Requesting 8.x-1.1 release
Comment #4
m.stentaAdded a list of non-stable modules we currently depend on. More than I expected... :-)
Also worth noting: farmOS itself will not be "stable" when beta is released... so maybe "beta blocker" is a little too strong for this. Needs more thought...
Comment #5
paul121 commentedAdding link to the Gin beta roadmap issue.
Comment #6
m.stentaviews_geojson tagged a new release - cross that one off the list!
Comment #7
mmjvb commentedhttps://www.drupal.org/project/csv_serialization/issues/3196564
https://www.drupal.org/project/entity_reference_integrity/releases/8.x-1.0
Comment #8
paul121 commentedAdding link to IEF 8.x-1.0 roadmap.
Comment #10
m.stentaThanks @mmjvb! Updated both and crossed them off the list! :-)
Comment #11
m.stenta@symbioquine has a pull request open to upgrade farmOS-map to 2.0.0-alpha.0, which is likely to be merged.
Adding farmOS-map as a blocker for this issue...
Comment #12
m.stentaMoving this to "stable blocker" as it does not need to block "beta".
Comment #13
m.stentafarmOS map is stable now.
Comment #14
m.stentaQuick update/thoughts:
fractionandlogare both maintained by me, and I plan to tag stable releases of those. Just waiting to see if anything else bubbles up from our farmOS 2.x dev process - but I think they are pretty much ready.entity_reference_validatorsandginare both currently inalpha.Everything else is either
beta(jsonapi_schema) orrc(inline_entity_form), and I don't have high hopes that either of those will change tostableanytime soon (they have large user bases and are relatively slow moving).So... maybe completely removing
minimum-stabilityisn't realistic. But if we could nudgeentity_reference_validatorsandgintobetathen we could at least set that as our minimum.Kinda defeats the purpose of removing it entirely I guess. Downgrading this to "minor", but I'll leave the "stable blocker" tag just in case things change between now and then.
Comment #15
m.stentaReleased Log 2.0.0.
Comment #16
m.stentaReleased Fraction 2.0.0.
Comment #17
m.stentaNow that Log and Fraction have stable releases, we no longer require and
*-devpackages, which means we could technically change"minimum-stability": "dev"to"minimum-stability": "alpha". But if we're going to take incremental steps with this, I feel like we might as well wait for Gin and Entity Reference Validators to go from alpha to beta and change it to"minimum-stability": "beta".Comment #18
m.stentaOh this is worth reviewing in more detail: https://www.drupal.org/node/3174472
Comment #19
m.stentaRemoving the "stable blocker" tag from this. It can happen after 2.0.0. There isn't much difference either way.
Comment #20
mmjvb commentedPropose the following strategy:
With minimum-stability applying to constraints of any package of your project, suggest to keep it as stable. You don't want dev versions of just any package. So, remove minimum-stability / prefer-stable from composer.json.
Apply @RC, @beta where needed, use exact branch/tag for dev or alpha.
Move @RC, @beta upwards as soon as possible. Monitor exact branch/tag and deal with new situation.
Document these situations for dependencies of primary requirements. Those need to be added as primary requirement allowing non-stable otherwise your requirements can't be resolved.
Comment #21
m.stentaThanks for the suggestions @mmjvb!
Since the last update, Gin released a beta, so the only remaining alpha we're using is Entity Reference Validators. I opened an issue for that in their queue in September, but forgot to link to it from this issue's description (updated now): #3239718: 8.x-1.0 Release.
Ah, does this mean that Composer won't complain about @RC/@beta, but will complain about @alpha? And the workaround is to specify the exact alpha release version? I didn't know that!
If so, then Entity Reference Validators is the only one we would need to pin. That's manageable!
Other than that, the project
composer.jsonis currently referencingfarmos/farmos: 2.x-dev, but once we release2.0.0(which I want to do very soon), then we can change that to^2. So perhaps we can do all of that at the same time.Agreed - and maybe we could open a follow-up issue for that specifically. The only projects we would need to monitor are Gin (@beta), Inline Entity Form (@RC), and JSON:API Schema (@beta but currently pinned to 1.0-beta1 since we are patching it).
Feels like we're close!
Comment #22
m.stentaAdding the "stable blocker" tag back again, with the above in mind. If we can do it as part of the
2.0.0release that would be great!Comment #23
m.stentaComment #24
m.stentaHmm I tried testing this and still got the following (with
minimum-stabilityremoved):farmos/farmos 2.x-dev requires drupal/entity_reference_validators 1.0-alpha2 -> found drupal/entity_reference_validators[1.0.0-alpha2] but it does not match your minimum-stabilityComment #25
mmjvb commentedIndeed, your project needs drupal/entity_reference_validators @alpha because farmos/farmos wants 1,0-alpha2.
This is what I meant to be documented, a dependency requires a non-stable not allowed by the project. The project needs to allow that. So your project needs drupal/entity_reference_validators @alpha, to be adjusted to @beta, @RC or removed when stable. Having the primary requirement for drupal/entity_reference_validators is only needed as there is no stable version yet.
Comment #26
m.stentaAh gotcha! Thanks for the explanation - I'm still learning new things about Composer all the time. Appreciate the insights! :-)
Well, perhaps we can try to nudge
drupal/entity_reference_validatorsto a beta release... that would be the best all around solution I think.I worry about adding it as an
@alpharequirement in our project'scomposer.jsontemplate, just because that will then need to be removed manually by anyone who uses the template in the future. Although I suppose once we require a non-alpha version infarmos/farmosthat would serve as a not-so-gentle notification to do so for downstream projects.Comment #27
mmjvb commentedWhen farmos/farmos is the template used for the project you need drupal/entity_reference_validators:1.0.0-alpha2 rather than 1.0-alpha2
In my previous reply thought that template had requirement for farmos/farmos the profile
These three need to be mentioned in the project template as :
Due to the nature of an alpha in semantic versioning would consider beta the minimum in a project.
Not sure about drupal/core 9.3.12, should be drupal/core ~9.3.12 at least for allowing bug fixes.
Comment #28
m.stentaThanks again @mmjvb - I did some more testing locally and I think I understand what's needed now.
Also thanks for pointing out this error... :-)
Ah I see that now. We need to declare all three. That's a shame, but it makes sense. It makes me wonder if we should just postpone this until these projects are stable.
We decided to pin all dependencies that we are patching, including Drupal core. I manually update this when security updates are released, currently.
Comment #29
mmjvb commentedYou either mention them in the project template so you know there are transitive dependencies wanting non-stable releases or you pin them like those you patch.
Although waiting for a perfect world is possible, not convinced that ever will be the case. Going for stable releases as much as possible warrants the work in my opinion. On top of stable you already patch.
You might want to consider other patch facilities. You should be able to provide release specific patching.
Comment #30
m.stentaAgreed - that's why I keep coming back to this issue. I'd really like to remove
minimum-stabilityandprefer-stablebefore our official 2.0.0 release if possible.Oh! I just realized: I think we can put these in the farmos/farmos
composer.project.jsonfile, which gets merged into the project templatecomposer.jsonduringcomposer install(via https://github.com/wikimedia/composer-merge-plugin).That would allow us to remove
minimum-stabilityandprefer-stablefrom https://github.com/farmOS/composer-project AND we wouldn't have to add any transitory dependencies there... they could be added in the farmos/farmos repo, which we can easily remove later, without requiring downstream project maintainers make any changes.I'll give this a quick test locally to confirm that it will work...
Comment #31
m.stentaHmm that doesn't seem to work, unfortunately. I suppose
wikimedia/composer-merge-plugin's logic does not run before the dependency tree determination logic does. Unless I did something wrong...Comment #32
m.stenta@mmjvb I've drafted a pull request: https://github.com/farmOS/composer-project/pull/8
What do you think?
The idea is: after we tag 2.0.0 of farmOS we can merge this. Then, if/as these dependencies release stable versions we can remove them from the project template
composer.json.Specifically I'm curious if this commit is roughly what you had in mind: https://github.com/farmOS/composer-project/pull/8/commits/a691e4758c8a81...
I used
_commentsto describe why these dependencies are included. I'm not sure if that's the best way to document, or if there are better alternatives.Comment #33
mmjvb commentedNo, not what I had in mind.
The farmOS/composer-project composer.json is the project template needing the three/four (farmos/farmos @beta) requirements to allow for non-stable transitive dependencies when removing minimum-stability.
You don't add the version constraint just the minimum stability. The version constraint belongs to the transitive dependencies, in this case the requirements of farmos/farmos.
The primary requirement of farmos/farmos in farmOS/composer-project needs to have ^2@beta as there is no stable release yet.
You don't add pinned dependencies to project template, there is absolutely no need for that. The minimum stability doesn't apply to pinned versions as there is no resolving the version, due to it being specified (pinned!)
No drupal/jsonapi_schema in template as it is pinned in farmos/farmos
Comment #34
m.stentaOK I may have misunderstood your suggestions then.
I'm confused by this:
The goal of this issue is to remove
minimum-stabilityfrom https://github.com/farmOS/composer-project/blob/2.x/composer.json (the project template). Are you suggesting we need to keep it?Looking back at your previous comments...
I must have misunderstood that. That is what this commit is doing, or so thought: https://github.com/farmOS/composer-project/pull/8/commits/a691e4758c8a81...
But you say that's not what you had in mind?
How do we achieve the goal of this issue (remove the
minimum-stabilityandprefer-stablelines) in another way?And just to respond to these two bits...
Oh I thought I ran into an issue without it... but I will double check that...
Sorry if that bit was confusing. Perhaps I didn't make it clear, but my broader intention is to tag a stable 2.0.0 of farmOS ASAP (we just have a few issues remaining). My plan was not to merge this PR alongside the 2.0.0 tagging of farmos/farmos, at which point `^2` would be the desired version constraint.
The next commit (https://github.com/farmOS/composer-project/pull/8/commits/a691e4758c8a81...) adds the alpha/beta/rc dependencies at the project level so that Composer doesn't complain when I remove the
minimum-stabilityandprefer-stablelines in the last commit (https://github.com/farmOS/composer-project/pull/8/commits/b73d678a48128c...).Comment #35
m.stentaOh I think I understand now... is this what you mean?
https://github.com/farmOS/composer-project/pull/8/commits/3d0ad2e3b1016d...
Comment #36
m.stentaUpdate: Entity Reference Validators is now in beta! That was our last alpha dependency! :-D
Comment #37
mmjvb commentedDecided to give you some time to think about the information I provided. No idea what made you think I would be in favor of using minimum-stability. Just for the record: Should be removed from Composer configuration, bad idea to use it, even in combination with prefer-stable. Should be deprecated as far as I am concerned. So, not suggesting to keep it in your project!
See #27 for those needed to be primary requirements due to transitive requirements (farmos/farmos). There could be more needed, any non-stable transitive dependency should be recorded as primary. Again, pinned version are not needed as they ar not affected, you do need to specify correct tag.
There should be no objection to maintain this in your project template. That is what its purpose is. Do like your idea of adding it to a separate file, using composer-merge-plugin to make them primary requirements.
You could/should change alpha to beta for Entity Reference Validators, but that is a minor detail. No effect when not done!
Suggest to work the other way around, specify what works now and adjust to changed circumstances. Don't anticipate future releases other than in constraints. So, currently you have farmos/farmos only available in alpha, which should be reflected in farmos/composer-project. This allows you to test now, no need to wait for all work to be done. The definition will provide expected results when circumstances change. Don't know you development plans, when farmos/farmos beta arrives you can test that with current specifications.
Also like the way you document. Maybe moving it under extra key to keep it valid json. Possibly adding topic to get comments organized.
Received your message from Slack, don't mind but prefer the Forum and Issue queue. Consider Slack a hostile environment, both participants and governance. Discontinued participation in Slack.
Comment #38
m.stentaThanks again @mmjvb - I think I'm caught up to your thinking now. Appreciate the pointers. And agree re: Slack. ;-)
I think I'm on the right track now and I agree this can be adjusted/committed before farmOS 2.0.0. Might as well get it done and close this issue.
Comment #39
m.stentaI found there's a bit of a chicken-and-egg with the
farmos/farmosversion constraint on this. So I've changed my mind and will wait to complete this until after2.0.0is released. Hopefully that will come together soon.Comment #40
mmjvb commentedWhat do you mean? Just trying to understand.
Comment #41
m.stentaVery minor detail. I tried changing from
"farmos/farmos": "2.x-dev"to"farmos/farmos": "^2@beta", ahead of the changes in this issue, but it fails because some of the beta releases depended on an alpha version of Gin:(beta1 through beta3 all depended on alpha Gin, beta4 updated Gin to its first beta release.)
I would rather just wait until we have a stable release of farmOS (coming very soon!) so that I can skip
"farmos/farmos": "^2@beta"entirely and just use"farmos/farmos": "^2". That will bypass the Gin alpha thing... one less thing to keep in my head right now, which is already full.Comment #42
mmjvb commentedThat doesn't make sense!
farmos/farmos beta4 requires gin beta.
Where do you get the message about gin alpha? Are you doing something on farmos/farmos beta 1,2 or 3 ?
Comment #43
m.stentaDownload the
composer.jsonfrom my2.x-minimum-stabilitybranch, runcomposer installand see if you get the same error that I pasted in my comment above: https://github.com/mstenta/farmOS-composer-project/tree/2.x-minimum-stab...Comment #44
mmjvb commentedNo problem
Comment #45
m.stentaHuh. I run Composer in Docker (not installed locally), and I was testing with the official Docker Hub
composerimage, which caused those errors to appear.sudo docker run -it --rm -v $PWD:/app composer installHowever, I'm testing again now with the
farmos/farmos:2.xDocker image, and it is working.sudo docker run -it --rm -v $PWD:/opt/drupal farmos/farmos:2.x composer installI know that the
composerimage is PHP 8, andfarmos/farmos:2.xis PHP 7.4 - maybe that is why I was seeing something different.It is working now. This makes me want to re-run some of my previous tests (eg: with
composer-merge-plugin) to see if they will work differently too.Thanks for double-checking this @mmjvb.
Comment #46
m.stentaComment #47
m.stentaComment #48
m.stentaBeen a long time since I looked at this....
entity_reference_validators,gin, andjsonapi_schemahave all had stable releases in the meantime.The only ones left are
inline_entity_form(see: #2576445: Inline Entity Form stable release plan) andconfig_update(see: #3384689: Provide stable 2.0 release).