move release-schedule PR into proposed state #7
Conversation
Flyingmana
commented
Dec 30, 2022
Flyingmana
commented
- Getting it moved into proposed state again by having 3 supporters
|
/cc @OpenMage/lts-admins @sreichel @ADDISON74 @colinmollenhour |
|
Not sure if it's in the scope of this rfc, but I think it's important to decide whether the releases will follow semantic versioning and mention that in the README, especially for people installing OM with composer since they probably expect that similar to the majority of other packages. |
|
All 3 alternatives are following semantic versioning, although alternative 1) is only indirectly mentioning it through the nginx reference. |
|
I will do an analysis from the perspective of a neutral user, as otherwise I could become subjective. The 3 alternatives shown are a good starting point. |
|
I vote for alternative 3, although I wouldn't have a fixed monthly release, we may be in the middle of some project and the repo could be in a "not ready for release" state. Also, 12 releases per year seem to much, the releases would be really small and less "interesting" when we need to create buzz around it (although a small changelog is easier to manage for the store owners, 12 releases/year will anyway create some headaches). I think 4 yearly releases it would be great. |
I take this as an "approved for moving into the next step, where we then can vote on it"? |
|
@Flyingmana if you want we could have a 3.1 (release monthly) and 3.2 (release quarterly). There would be a 4 (main + only backport extremely important stuff to the "previous" version) but that's kinda covered by #6 so I don't know about that. |
|
Maybe we should approach from another perspective. For example, at a PRs number or at a number of months, obviously excluding the situation where a new emergency version is desperate needed. If we have 100 PRs in a month we can release a new version every month, but if we have 10 PR, we release it every 4 months. I take in consideration the effort of those who make this process possible. It would be good to discuss. |
mmmm interesting, it makes a lot of sense
that's a whole different Pandora's vase :-) it's an interesting discussion to have but I think it's outside the scope of this specific RFC |
|
The 3 proposed solutions are good IMO. So this is ready to move to the next step. |
|
I do count 3 supporters now, this means we are ready to move this to proposed and start the actual voting phase, right? |
Just picked this comment ... and ... https://github.com/OpenMage/organizational-internal/issues/14 I can understand that you want to follow semantic versioning, but can we do this? If something went wrong can we provide a "hot-fix" release in time? Who decides what requires a patch/minor/major release? For me it still looks like some overhead. Suggestion: Adding monthly releases ... or earlier depending on count of commits PRO: less conflicts/trouble to get PRsl merged |
that would be something for a different RFC. Till then I would say, everything which is a breaking change for any user/Theme/ExtensionVendor, it has to go into a new Major Release. A single theoretical Case should be enough for it. Iam undecided about minor versions, as long as we regularly merge in new features, it would make sense to release them as minor versions, which means usually only the newest branch gets minor releases, everything else only bugfix releases. But yes, that should go into a different RFC |
Think the semver site already defines that. |
true, but at the moment we didn't have any trouble deciding "ok let's release", and also the "which release number are we bumping too" went smoothly, so I wouldn't worry too much about that :-) |
I know. But do or can we follow this. (just a question) |
|
Can this move forward now? |
|
I updated Alternative 1, I hope it's ok, it was based on a suggestion I had proposed at one point and I don't think it was very popular anymore and wasn't very well defined anyway.. The new alternative is my best proposal based on observations from the past three years. |
…ilar to 1 but less well defined.
|
Now that you have simplified things and eliminated alternative 3, I vote for alternative 1. Realistically speaking, do you think we will ever have a major release? What could this contain to name it major? So far, apart from small features, we have mainly patched Magento to bring it to 2023. I could consider the replacement of the unmaintained Zend library with ZF1-Future a major change. Another could be to specify that OM is tested and fully functional with PHP 8.2. |
|
I think this is a great RFC, it will have my vote. |
|
It must be approved by "green people" only. |
Co-authored-by: Fabrizio Balliano <fabrizio.balliano@gmail.com>
|
@Flyingmana I'd like your blessing on this as it was your PR to begin with and I sorta hijacked it.. :) If you have no objections or additional changes to make please merge it and create the PR for "accepted" so everyone can vote. Looking forward to having this settled! |
|
it has my full blessing, for me it was just important to have a democratic base behind the decision, which we have now. But have currently 9 private things I need to finish before I can check back on it and do something |
|
I've re-read everything and I like it, just a question @colinmollenhour, can we avoid having a "next" branch if we don't have any major development going on, and create it when needed? |
I think that would make it difficult for non-admins to create MAJOR update PRs based on the next branch and therefor discourage proper use of "next" as the merge base for the PR. I suppose you're concerned about "next" getting significantly behind "main" when there is not a lot of active development on MAJOR updates? |
true, although I guess people would open the PR on the main branch, we would say "great, this is a major change, let's create the next branch and rebase the PR", it would seem like the normal flow, what do you think?
no it's actually more about having to update it constantly and maybe we don't even need it for many months |
|
An explicit rebase step (if that's what you meant) might not even be necessary, I think just changing the PR is all that is needed. However this clause would be broken if there was not always a "next" branch:
Perhaps a Github action could auto-merge all "main" updates into "next" if and only if it is possible with a fast-forward? Then the manual maintenance would only start when next is different from main. |
|
It looks like there are a few possibly relevant options already:
So maybe this could just be considered later as an incremental improvement on the workflow after it is fully realized.. |
|
mmmm ok, I still would prefer to have the next branch when needed but these action would work perfectly since there would be no conflicts ;-) |
|
we've 2 green checks and 2 grey ones, can we try to move this forward? |
|
Time to merge and vote! how do we vote anyway? 😅 |
|
From the repository README:
|
|
but the rule for merging was 3 green checks, I didn't force the merge, the button was green, and #4 didn't have 10 votes, that's why I was pretty sure it was safe to merge... |
This PR is fine, my comment was about the voting phase. I suppose create a PR that moves the file from "proposed" folder to "accepted", and that's where the final voting can be done. |
|
ah yes sure! 😅 sometimes I freak out I did some weird mistake |
|
Actually I'm a bit confused too, It seems that the last RFC went through one step only. |
|
I started a new PR to move to accepted. Please vote there: #10 |
