Like I said in the message: trunk/wicket-1.x/ will be the main development stream for 1.x versions. It will be the HEAD for 1.3, 1.4, 1.5, 1.6
trunk/wicket-2.x/ will be the main development stream for 2.x versions. It will be the HEAD for 2.0, 2.1, 2.2, 2.3, etc. For 3.x we'll have to see when that happens. We're working on 2 seperate wicket versions at the same time. We're forked. Better reflect that in the repository than having the problems for 1.2, 1.3, 1.4 etc. Where should 1.3 in your proposal stay? branches/WICKET_1_2 ? Or should we create another branch? branches/WICKET_1_3? and make that our primary development stream for wicket 1.x? When should we do create that branch then? How can we prevent people from committing something to 1_2 instead of 1_3? Martijn On 8/20/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > I dont know about this > > Where will 1.3 reside? and 2.1 ? > or 3.x ? > > (or better said 2.0 when we have released it) > > 1.2 is just a a branch in my eyes. Ok not really a maintenance branch but > something more. > But it is in my eyes still a branch > > I just like this > > trunk == wicket X (the last wicket where we work on) > > branch == wicket1.2/wicket1.3 en wicket2.0 when trunk is now wicket2.1 > > And always tag all the (final) releases we do under tags > > > On 8/20/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > There has been some confusion on the branches and Wicket 1.x > development. This document proposes a solution to this confusion, and > asks for a vote on structure. But first a short analysis of the > problems at hand. > > According to me, the root cause of this confusion is that we have > effectively two main development streams: Wicket 1.x and Wicket 2.x. > The Wicket 1.x main development stream happens in the branch, and 2.x > development happens in trunk. This effectively makes it harder to > distinguish between release branches (1.2.1 for instance) and > development branches. > > To make the distinction more clear on what constitutes the main > development streams, I propose to split our current trunk into two > forks: wicket-1.x and wicket-2.x. The future development of Wicket > will still remain in wicket-2.x, but for support of those already in > production we keep the latest version of wicket-1.x up to date with > bugfixes and backports. > > The solution to our problem at hand is that we should: > 1. move trunk/ to trunk/wicket-2.x/ > 2. move branches/WICKET_1_2/ to trunk/wicket-1.x/ > 3. copy the specific 1.2 release moment (the actual revision when the > 1.2 branch was created) to the branches/WICKET_1_2 directory. > 4. copy WICKET_1_2 (the point where the branch was created) to > tags/WICKET_1_2 > 5. copy WICKET_1_2_1 (the point where the branch was created) to > tags/WICKET_1_2_1 > > This way people can get to the bare starting point easier (look in > tags/) or check out the branch if they want to replicate the build > itself. > > The final repo directory structure would then be: > > svnroot/wicket/ > branches/ > WICKET_1_2/ <- final build for 1.2 > WICKET_1_2_1/ <- final build for 1.2.1 > tags/ > WICKET_1_2/ <- marking start of 1.2 > WICKET_1_2_1/ <- marking start of 1.2.1 > trunk/ > wicket-1.x/ <- main development of 1.x (1.2, 1.3, etc) > wicket-2.x/ <- main development of 2.x (2.0, 2.1, etc) > > If we were to implement this, then *after* the repo repair, the 1.2.2 > build would look like the following: > > 1. create tag from trunk/wicket-1.x/ : tags/WICKET_1_2_2 > 2. copy tag to branch: branches/WICKET_1_2_2 > 3. create release from branch, commit release changes to branch > 4. merge improvements from WICKET_1_2_2 branch to trunk/wicket-1.x and > trunk/wicket-2.x when applicable. > > So both in tags/ and branches/ WICKET_1_2_2 tags will be available, > where the tags *mark* the release point in time on the trunk, and the > branch will contain the artifacts particular for that release. > > Please vote for this proposal, committers have binding votes. The vote > will last for 48 hours. > > Martijn > > -- > Download Wicket 1.2.1 now! Embed Wicket components in your portals! > -- 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 > > > ------------------------------------------------------------------------- > 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 > > > -- Download Wicket 1.2.1 now! Embed Wicket components in your portals! -- 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
