aahz> Yup. The idea is that because it's always an N and N-1 pair, the
aahz> base code is the same for both and applying patches to both should
aahz> be (relatively speaking) a small amount of extra work. Most of
aahz> the work lies in deciding *which* patches should go into N-1.
The only significant problem I see is making sure submitted patches contain
just bug fixes or new features and not a mixture of the two.
aahz> The main reason I suggested two betas was to "lockstep" the bugfix
aahz> release to the next version's feature release.
I don't see any real reason to sync them. There's no particular reason I
can think of why you couldn't have 2.1.1, 2.1.2 and 2.1.3 releases before
2.2.0 is released and not have any bugfix release coincident with 2.2.0.
Presumably, any bug fixes between the release of 2.1.3 and 2.2.0 would also
appear in the feature branch. As long as there was someone willing to
manage a particular bug fix branch, such a branch could continue for a
relatively long ways, long past the next feature release.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4