Three things to keep in mind, IMO. First, people dislike too many choices. As the version numbering scheme and branches go up, the confusion level rises (it's probably like for each dot or letter you add to the version number, the number of people who understand which one to grab goes down an order of magnitude. :). I don't think it makes any sense to do more than one branch from the main trunk, and then do bug fix releases along that branch whenever and for as long as it seems necessary. Second, you probably do not need a beta cycle for patch releases. Just do the 2.0.2 release and if you've royally hosed something (which is unlikely but possible) turn around and do the 2.0.3 release <wink> a.s.a.p. Third, you might want to create a web page, maybe a wiki is perfect for this, that contains the most important patches. It needn't contain everything that goes into a patch release, but it can if that's not too much trouble. A nice explanation for each fix would allow a user who doesn't want to apply the whole patch or upgrade to just apply the most critical bug fixes for their application. This can get more complicated as the dependencies b/w patches goes up, so it may not be feasible for all patches, or for the entire lifetime of the maintenance branch. -Barry
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