Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
SEP 14 - Changes to branching and release strategy #20
@mchugh19 we're removing the release # requirements - it may be 3 releases, it may be 12 (though that's unlikely
That means regardless of the number of releases we make per year, you can always rely on getting at minimum a year of warning before your feature is removed. This will also be called out in our changelog (see SEP 1), both when the deprecation warning is added, as well as when the actual feature is removed.
So if we cut 3 releases per year, yes, we will warn for 3 releases. If we cut 10 then we will warn for 10 releases. Seem reasonable?
The SEP doesn't mention a feature freeze period; however, during the last office hours, it was said to be ~1.5 months (1 before and 0.5 after a release).
Maybe I misunderstood the exact branching strategy, but it looks like the master branch would be feature frozen. This feels a bit long compared to 4 month release cadence.
A backlog of unmerged features means that they aren't integrated together, and although individually the PRs could be green, lots of conflicts and test failures are expected during the merge stage.
You might want to consider making a temporary RC branch to prevent the backlog and avoid blocking the master branch from merges.
I think the biggest problem would just be a lengthy cycle (e.g. a month-ish) to merge the changes.
There is definitely some (understandable) caution around making the release branch, but one approach that we could take is to create the release branch at the moment of RC (one month before release).
Then we would only merge bugfixes (preferably issues for which there are no workaround) into RC, while we could still merge new things into master.
What concerns me the most about this approach is the practicality around the bug fixes. Will we:
It sounds like there is going to have to be a tradeoff here - which one are we most comfortable with? Delaying feature PRs periodically? Some extra overhead in merging things?
Perhaps there's other, more simple solutions that I haven't encountered. If not, what trade off are we most comfortable with?
I think that if we don't have time (or inclination) to write regression tests for issues that we're fixing, it's probably a good idea to call that out. I've found that writing tests for Salt is a great way to learn more about what it's doing in any particular place. We could definitely add the
For bugs that are more integral to Salt, I'm sure that the core team could take that on. Though it's definitely better if the contributor who is most recently familiar with the issue would write the tests.
For bugs in some less popular areas I'm sure it makes sense to expect some push back
It should be a PR created on the RC branch which is made up from cherry-picked commits against the master branch. IMHO, a system of labels should also be created to help manage this process so we know what needs to be backported and what remains.
Here is a tool that will do all of this for you: https://github.com/sqren/backport
tl;dr - I was concerned, but now I'm a huge fan of the feature freeze, because back-of-the envelope calculations.
That sounds like what we used to have... and what we've seen is that it becomes impossible to track down what problem was introduced when, where, and why. It also becomes easy to lose track of what needs to be where.
If we simply say, "Code isn't shipped unless it's in master," then we eliminate all of those problems - for people trying to push code, for people trying to maintain the project, and people trying to use the code.
I think that this feature freeze is actually a good thing.
If what we're saying is that bug fixes can be merged (with tests) at any point then Salt should always be getting more stable. Bug fixes will continually get merged in during the the entire process.
If the feature PR continually breaks with every subsequent bugfix PR, that's an indication that we need to pay special attention to it because it's causing massive changes across the codebase. We probably need the month and a half to give it a proper review, build some manual test cases, etc.
To imagine a worst case scenario, let's say that 50 features are going to get merged into Salt for the Aluminum release. Let's say we're at a 3-month cycle by that point. If we remove the 2 weeks post-release and the 4 weeks pre-release that gives us 8 weeks, or about 7 features per week. Since each PR has to be built on the most recent master with passing tests, that means that each time we merge, we're going to have to wait for a rebuild before we can merge the next one. Realistically that means we might be able to merge one in the morning, one in the evening. So, we probably could merge 7 features per week - in theory assuming no merge conflicts and all passing tests we could even do up to 14, giving us a(n extremely theoretical) capacity of 100 features shipped per release.
I was actually kind of concerned about the 1.5month wait, but now that I've done the math I'm not really concerned anymore. In the past it's not like we were able to deliver a shorter release cycle (in fact, we've been pretty good about missing releases and throwing features in point releases because it's not that big of a feature). We're not taking away anything that we were able to deliver on before, in fact we're probably going to be able to deliver more features faster just by sticking the feature freeze into effect. The other advantage is that by giving ourselves a month to fix bugs, if a feature is accepted a little prematurely we stand a much better chance of catching it and fixing the problems before it gets into an official release.
Could you please help me understand where the trouble would be? If all original contributions are to master and all cherry-picks are from master, couldn't you always bisect master to find any regression?