New proposal, based on Upavayvira's idea: trunk/ <- wicket 2.x/3.x/4.x development, always the newest *MAJOR* version stream branches/ <- previous major/minor versions development sandbox/ <- developer/try workspace releases/ <- all releases will be committed here, fixing versions, readme's, etc. tags/ <- marks the start of *a* release, or any other point in the repository, considered to be read only
- all development for the newest, greatest and baddest Wicket release (currently 2.x) will be performed in trunk/ - all main development for newer releases based on older Wicket technology (currently 1.2/1.3) will occur in branches/WICKET_(0-9)_X (e.g. branches/WICKET_1_X and branches/WICKET_2_X), where the _X is not substituted with a number, but is taken literally. - all releases will be tagged in tags/ using START_RELEASE_WICKET_P[_Q[_R]] - all minor releases (_1_2, _1_3) will be receive a branch in branches/ (e.g. branches/WICKET_1_2, branches/WICKET_1_3 and branches/WICKET_2_0), only bug fixes for a particular release will be made to this branch. - all non-development (i.e. non-alpha and -beta) releases will be copied to releases/ using WICKET_P[_Q[_R]] (e.g. releases/WICKET_1_2_2 and releases/WICKET_1_3). The created location is *only* for release specific material. So to spell out an example: Wicket 2.0 is released. This means: * copy trunk/ to tags/START_RELEASE_WICKET_2_0 * copy tags/START_RELEASE_WICKET_2_0/ to releases/WICKET_2_0 * copy tags/START_RELEASE_WICKET_2_0/ to branches/WICKET_2_0 * check out releases/WICKET_2_0 in a clean workspace * build release, fix version numbers and do the maven magic to build the wicket release. * commit changes to releases/WICKET_2_0 New development for 2.1 continues in trunk. Only bug fixes are committed to branches/WICKET_2_0 and merged to trunk Wicket 2.0.1 is released. This means: * copy branches/WICKET_2_0 to tags/START_RELEASE_WICKET_2_0_1 * copy tags/START_RELEASE_WICKET_2_0_1 to releases/WICKET_2_0_1 * check out releases/WICKET_2_0_1 in a clean workspace * build release, fix version numbers and do the maven magic to build the wicket release. * commit changes to releases/WICKET_2_0_1 New development for 2.1 continues as done previously in trunk. Bug fixes to 2.0.1 are committed to branches/WICKET_2_0 and merged to trunk Wicket 2.0.2 is released. This means: * copy branches/WICKET_2_0 to tags/START_RELEASE_WICKET_2_0_2 * copy tags/START_RELEASE_WICKET_2_0_2 to releases/WICKET_2_0_2 * check out releases/WICKET_2_0_2 in a clean workspace * build release, fix version numbers and do the maven magic to build the wicket release. * commit changes to releases/WICKET_2_0_2 New development for 2.1 continues as done previously in trunk. Bug fixes to 2.0.2 are committed to branches/WICKET_2_0 and merged to trunk Wicket 1.3 is released. This means: * copy branches/WICKET_1_X to tags/START_RELEASE_WICKET_1_3 * copy tags/START_RELEASE_WICKET_1_3/ to releases/WICKET_1_3 * copy tags/START_RELEASE_WICKET_1_3/ to branches/WICKET_1_3 * check out releases/WICKET_1_3 in a clean workspace * build release, fix version numbers and do the maven magic to build the wicket release. * commit changes to releases/WICKET_1_3 New development for 2.1 continues in trunk. New development for 1.4 continues in branches/WICKET_1_X, only bug fixes to 1.3 are committed to branches/WICKET_1_3 and merged to branches/WICKET_1_X Wicket 1.3.1 is released. This means: * copy branches/WICKET_1_3 to tags/START_RELEASE_WICKET_1_3_1 * copy tags/START_RELEASE_WICKET_1_3_1 to releases/WICKET_1_3_1 * check out releases/WICKET_1_3_1 in a clean workspace * build release, fix version numbers and do the maven magic to build the wicket release. * commit changes to releases/WICKET_1_3_1 New development for 1.4 continues as done previously in branches/WICKET_1_X. Bug fixes to 1.3.1 are committed to branches/WICKET_1_3 and merged to branches/WICKET_1_X This is IMO a solid, and clear configuration management solution to the two development streams we currently have to support. As you can see, both the procedures for TRUNK development and 1.x development are the same, the only difference is that 2.x commits are done in trunk, and 1.x commits are done in branches/WICKET_1_X (literal). Bug fixes to a release are always performed in a specific minor release branch, i.e. branches/WICKET_2_0, branches/WICKET_2_1, etc. Bug fix releases will not receive a place inside branches/. Release *build* particulars are committed to svn in the /releases/WICKET_1_2, /releases/WICKET_1_2_1, /releases/WICKET_1_2_2 etc. directories. Martijn ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
