On 18/09/2014 20:25, Joe Taylor wrote: > Hi all, Hi Joe, > > In preparation for the public beta release of WSJT-X v1.4 planned for > October 1, we need to agree on a revision number for the code and > supporting files that will be tagged in the repository, made into a > *.tar.gz file, etc., for the release. > > At present we're at revision 4337. As a straw-man proposal, I'd like to > suggest that any changes between now and Oct 1 should be bug fixes, > i.e., repairs of existing functionality. This means no new features in > the next 12 days. Is everyone OK with this? Do you foresee a need for > other changes? I may have to bend this a little but my new feature changes will not effect the WSJT-X revision number since they will be in Hamlib. > > Also: to allow time for building Linux and OS X release packages, we > need to tag the revision to be used release at least a few days before > Oct 1. Does September 26, a week from tomorrow, seem reasonable as a > target "tag date" ? > > We have never been so formal about such things in the past, but now that > we have a much larger and more active development group it seems the > right thing to do. Am I forgetting anything important? Don't forget that you can always check out a past revision and make a kit from that so changes can flow in continuously so long as there is some control on potentially breaking changes running up to the fork point.
I suggest that the SVN revision number not be used in any file names or documents, the tag v1.4.0 should be the definitive tag and the SVN revision number just a side effect of the actual revision chosen to tag. I.e. tag the Beta revision as v1.4.0 (more correctly v1.4.0-rc1) and immediately update the version number in Versions.cmake so that any new build gets a different id. After that we can either decide to remain feature frozen until v1.4.0 is released or branch for bug fixes with the "main line" being bumped to v1.5.0 (or v1.4.1) and fixes going into the v1.4.0 branch and also merged into the "main line". The latter parallel new features plus a feature frozen branch destined to be a release is a more normal procedure but we could simplify to the former with no new features through -rc2 .. -rcN until v1.4.0 is released. I prefer the branched model personally as branches are very cheap in source control systems and merging of bug fixes is easy so long as all developers working on the release candidate branch understand that they must merge all fixes into the "main line" as well using the appropriate SVN merge command so that a proper SVN history is maintained. > > -- Joe, K1JT 73 Bill G4WJS. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
