Very much agree with this view. If there is a feature the needs extensive user review/testing, we can do `beta' release on a feature branch.
Göran Uddeborg <[email protected]> writes: > Mark Diekhans skrev: > > I come from old-school, with a release branch being made and > > going through alpha and beta releases with tags marking them. > > > > Although, many git projects have moved away from this and keep > > main branch release-quality and just cut releases off of it. > > This seems attractive. > > I come from that old school too, but have been convinced by the newer > schools. > > There is room for argument if release branches still are useful for > large projects with many changing parts in each release, like e.g. > GCC. > > In more moderate or small projects, it is my experience keeping main > release quality all the time actually works fine and reduces overhead. > (In some projects one might OCCASIONALLY need to make a release branch > from one of those releases with an urgent patch if main isn't kept as > good as it should be.) > > It would be fine with me to have any new developments done in feature > branches. When ready, the branch is merged, and we could set up CI to > automatically tag it as a new release. I'm not insisting on this, but > I believe it would work fine. > > We need to come to a state where we trust main is good enough before > doing this, of course.
