-Igor
On 8/23/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
-------------------------------------------------------------------------
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
