errrr....... may I chip in a couple of thoughts. Let's start with Adam and Eve. There is a code tree and there are release files, like wicket-1.2.1.zip. The code tree is managed by subversion and the release files are published at sourceforge. Technically a committer could commit into any part of the code tree and also technically a 'releaser' could take the source from any part of the tree as he likes. Both would be technical legal, svn doesn't set any technical restriction and the releasing process of the files doesn't either. To make ends meet certain morals have to be established.
First the morals concerning the use of subversion: Often one reads that the bleeding edge code has to be committed into the trunk and code for releases has to be commited to the branches and code in tags is not developed on. Even though that's morally right, its no technical restriction, the only technical restriction is: You commit, the revision number of the repository increases by one! If i understand the current release process right, a three digit release numbering scheme is intendet, like wicket-A.B.C.zip. Whereas chances in the A digit are meant for mayor architectual changes, definitely not a drop in release. Changes in the B digit show mayor feature changes, most likely not a drop in release and at the end C digit changes are meant for bugfixes and minor feature changes, likely a drop in release. For this I'd propose the following directory structure for the repository tree: trunk/ (bleeding edge, possibly: wicket-3.0) branches/WICKET_2_X (Code for the next B digit change release, here for: wicket-2.0) branches/WICKET_1_X (Code for the next B digit change release, here for: wicket-1.3) branches/WICKET_1_2_X (Code for the next B digit change release, here for: wicket-1.2.2) Now comes the interesting part, someone decides that it's time to settle for wicket-1.2.2: svn copy branches/WICKET_1_2_X branches/WICKET_1_2_2 This changes the semanticts of the code tree: trunk/ (no change) branches/WICKET_2_X (no change) branches/WICKET_1_X (no change) branches/WICKET_1_2_X (now this is the code for wicket-1.2.3) branches/WICKET_1_2_2 (now this is the code for wicket-1.2.2) Now its time for the releasing guy, that's Martijn, I think. As he thinks it's time for releasing the wicket-1.2.2.zip file he starts out with: svn copy branches/WICKET_1_2_2 tags/WICKET_1_2_2 There are two things to watch out for: 1. Event though any comitter could commit to tags/WICKET_1_2_2 only Martjin should! 2. Once tags/WICKET_1_2_2 is created any commits to branches/WICKET_1_2_2 might get lost, if Martjin is not informed. Basically branches/WICKET_1_2_2 is a dying branch then! Now the tree looks like this: trunk/ (no change) branches/WICKET_2_X (no change) branches/WICKET_1_X (no change) branches/WICKET_1_2_X (no change) branches/WICKET_1_2_2 (dying branch, commits might be lost!) tags/WICKET_1_2_2 (code under controll of the releaser, meant for wicket-1.2.2.zip) As the releasing guy is comfortable with tags/WICKET_1_2_2 he creates the release file wicket-1.2.2.zip. Once the releases file is created tags/WICKET_1_2_2 freezes, no commits no more on that tag. So once wicket-1.2.2.zip is shipped to sourceforge the code tree has this meaning: trunk/ (no change) branches/WICKET_2_X (no change) branches/WICKET_1_X (no change) branches/WICKET_1_2_X (no change) branches/WICKET_1_2_2 (dead branch, commits are lost!, bound for deletion) tags/WICKET_1_2_2 (this tag is frozen, code identicall to code used for wicket-1.2.2.zip) Besides the described responsebilities for the developers there are some implicit responsibilities: Basically any code committed to trunk or branches/WICKET_A_X will eventually go into a release file sooner or later. A developer has to decide if his code changes need to be merged into the developing branches of future releases. If you commit to a fully numbered (without an X) branch, always look out for a corresponding tag. As I said, my 50 cent on this subject, hope I wasn't to intrusive, Martin Martijn Dashorst schrieb: >Let me reiterate: *I* have a strong desire to commit changes to the >project files I make during a release build. *I* therefore need a >place to commit them. > >branches was not good. releases is not good. what is left? Shall I >just go forward and do it the way I seem fit? > >Martijn > >On 8/24/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > >>fine by me except that i don't really like this: >> >> >>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 >>> >>> >> >>and then the last sentence. what does that mean? commit changes to that >>release? >>(releases tag is for me the same as "tags" it should be readonly) >> >> >>johan >> >> >>------------------------------------------------------------------------- >>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
