I think a release branch serves several purposes, among others: -ability to add changes that are specific for the release (in case of NetBeans things like: release branding, updating module spec. versions to release format, disabling exceptions, etc.) -let development (features and general bugfixing) continue even during the late pre-release stages. This may include: --allowing bugfixes that are not crucial, or simply too dangerous, for the release --allowing (shared) development during the final stages of the release (in our current situation, this may take quite some time: voting for a release cadidate takes roughly a week (3 days here, 3 days on the incubator), so if the release votes fail a few times, the final stages can easily span several weeks) -ability to release update release for several past major releases (not that this would be used much in NetBeans in the past)
I think feature branches are good to develop a (biggish) feature, but when it is (almost) ready, it needs to be part of some kind of a shared branch, otherwise people won't (be able to) test and use it. I agree that the mainline should work as best as it can (and I am myself running a bleeding edge NetBeans on a bleeding edge JDK), but I think this is for folks that don't mind (too much) reverting to their last good build if the new one does not work good enough (which inevitably happens from time to time, when using bleeding edge). Jan On Thu, Apr 26, 2018 at 4:08 PM, Wade Chandler <wadechand...@apache.org> wrote: > +1 and even if we don’t have a “dev” branch, I think we should be able to > release from master without branching. We should be working to stabilize > things near a release, and perhaps we ask folks not to merge new features > to master, but only fixes for a period of time. If we could support feature > flags, then even better, and for new modules and such I think we can > through configuration and clusters, to not have them enabled and included > by default, but not with big new features to existing modules. We would > need new switches in the config file for those. Then new work can be > enabled or disabled for a release depending on how far along it is. > > Either way, I feel master should always build, run, and be as stable as > possible. Now, in this interim phase where we are still trying to get over > to Apache all that is NB, it may be harder or nearly impossible since it is > so much to bring over, but I think that should be our goal going forward > once the “drop” has happened. > > My $0.02, > > Wade > > > ======================= > > Wade Chandler > e: cons...@wadechandler.com > t: @wadechandler > https://www.linkedin.com/in/wade-chandler > > > > On Apr 17, 2018, at 10:09 AM, Christian Lenz <christian.l...@gmx.net> > wrote: > > > > Master shouldn’t be that one, where the wild development is going on. > Master should be that one which is already live. > > In General, what gitflow does. Wild development is going on on the dev > branch, for the next release. If whatever is finished, there is a release > branch. After that, it will merged into master and created a tag. > > > > If this is not possible, then an other solution is that develop stays > clean and always releasable. You only work on Feature branches. After the > Feature is finished and ready to go, it will merged into develop. Someday > you can create a release branch of develop. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
