A couple of things still worry me, specifically tagging... 1) Is there any need to keep "tags/START_RELEASE_WICKET_2_0" once you've copied it to "releases/WICKET_2_0" & "branches/WICKET_2_0"?
2) After "commit changes to releases/WICKET_2_0", shouldn't we have a "copy releases/WICKET_2_0 to tags/RELEASE_WICKET_2_0"? Notes: I don't like the idea that we're not tagging the exact release version, which is the dichotomy introduced by the 'release branch' idea. If someone wants to take the source & build it locally, what should they use? I'd expect that anyone coming to this with normal SVN experience will expect that a tag called anything like "RELEASE_WICKET_2_0" would involve the actual release version. (Prefixing it with "START_" won't mean anything unless there's another tag with either "END_" or no prefix.) If there are no tags, then they might look elsewhere (/releases?) but the expectation will be to use /tags. If they do however, they've got to take on trust that the differences between that and the actual release source are not significant for them, whereas I'm not really sure that's a good idea... /Gwyn On 23/08/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > 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 > -- Download Wicket 1.2.1 now! - http://wicketframework.org ------------------------------------------------------------------------- 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
