How about this then: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ (snapshot version of JSF 1.2 based)
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/1.0.current/ (snapshot version) https://svn.apache.org/repos/asf/myfaces/trinidad/branches/1.2.4 (created during pre-release) https://svn.apache.org/repos/asf/myfaces/trinidad/branches/1.0.4 (created during pre-release) Then it is up to the individual commiter if he/she wishes to add the functionality to 1.0.x or not. The "current" folder would allow people to work on 1.0.5 while 1.0.4 isn't released yet though (behaves like a trunk without the "trunk" name). -Andrew On 10/25/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > +1to this. I do agree that "unsupported" too strong, but having to > support dual code-lines for enhancements is hindering enhancements to > Trinidad. It should be the responsibility of the 1.2 branch to make > sure that people moving from 1.0.x to 1.2 have an easy upgrade path but > I see no reason to allow someone who uses 1.2 specific features to go > back to 1.0.x... > > Scott > > Matthias Wessendorf wrote: > > Also the fact, that JSF 1.2 is the most current JSF version, would be > > a valid reason for making trunk become the 1.2.x version. > > > > What about supporting 1.0.x at a minimal level ? > > like "important" fixes make it into, but no "new feature" makes it into ? > > Like a "1.0.3.x " series ? > > > > WDYT ? > > > > -M > > > > > > > >> I would definitely prefer that 1.2 is the main trunk sooner rather than > >> later. We have to weigh the risk of bug fixes and features not getting > >> merged into the 1.1 branch versus their not getting merged into the 1.2 > >> branch. Given that the 1.2 branch will eventually be the main trunk > >> anyway, > >> the choice comes down to: > >> a) Fix isn't merged into 1.2, resulting in a regression when 1.2 becomes > >> the main trunk > >> > >> vs > >> > >> b) Fix isn't merged into 1.1. 1.1 branch works no worse than it did > >> before > >> the patch was applied. > >> > >> As a practical matter, merging and testing in both branches is a > >> significant overhead. Most developers weren't experiencing this overhead, > >> as Adam Winer handled most of it. > >> > >> -- Blake Sullivan > >> > >> > >> > >> Matthias Wessendorf wrote: > >> On 10/24/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > >> > >> > >> On 10/24/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > >> > >> > >> IMO, the 1.1 would still act as the main trunk for new features that > >> are not 1.2 specific. It would then be a choice of each committer to > >> patch 1.2 trunk or not (is the "or not" an option or not though -- > >> should we require it so that the maintainers don't have to do all the > >> svn merging?). > >> > >> Personally I prefer 1.1 OR 1.2 being the "main trunk". > >> > >> Should say "I don't prefer... " > >> Meaning I don't care if 1.1 is main or 1.2. > >> Both should be maintained in the same way. > >> > >> > >> > >> I am working inside a JSF 1.2 environment (like you ;-) ), > >> > >> My main concern is that these "trunks" have a separate live. > >> I personally think, that the committers should "port" the patches > >> (created or provided via contributors) to the other trunk as well. > >> > >> Some just can't use 1.2 or 1.1 so, would be odd if a bug is only fixed in > >> one. > >> > >> > >> > >> > >> Only if the feature is 1.2 specific would it be placed only on the 1.2 > >> trunk. > >> > >> that's for sure. > >> > >> > >> > >> This could work like: > >> > >> 1) work on 1.1 and optionally port to 1.2 > >> > >> I think working on 1.2 and port optionally to 1.1 doesn't make a > >> difference. > >> Just the other way around. > >> > >> > >> > >> 2) apply 1.2 changes only to 1.2 > >> > >> +1 > >> > >> > >> > >> 3) on release, branch 1.1 and 1.2 at the same time > >> > >> and provide same releases at same time: > >> 1.0.4 && 1.2.4 > >> 1.0.5 && 1.2.5 > >> ... > >> > >> > >> 4) apply 1.1 changes from the 1.1 branch (merge) to 1.2? (unless we > >> require committers to maintain their change on both trunks) > >> > >> I'd love to see this "restriction" :) > >> > >> > >> > >> opinions? > >> > >> On 10/24/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > >> > >> > >> I like the idea of have two trunks. > >> > >> My only concern is that, these two live different lifes :) > >> I can see that some only maintain 1.2x and some only 1.0x > >> > >> Perhaps setting a "committer" rule, to port patch to other branch, WHEN ! > >> these > >> patches aren't specific to a particular version (like JSF 1.2 - API) > >> > >> wdyt ? > >> > >> On 10/24/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > >> > >> > >> This has been brought up in the past (1.2 trunk), but it is again a > >> hot topic here at oracle for applying trinidad patches. > >> > >> Currently we have in SVN: > >> > >> https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad > >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/1.2.x-branch > >> > >> The problem with this structure is that there is a window between a > >> trunk release and a branch release where there is no place for > >> development on the 1.2 branch. Take now for example: > >> > >> 1.0.3 (Released) > >> 1.0.4-SNAPSHOT (Trunk - dev) > >> 1.2.3-SNAPSHOT (branch - pre-release) > >> > >> There is no 1.2.4 area for people that are making 1.0.4 changes to > >> apply to the 1.2 branch. > >> > >> Would ppl. be in support of an SVN re-architecture for the following > >> general structure? > >> > >> https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/jsf-1.1/ > >> (snapshot version) > >> https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/jsf-1.2/ > >> (snapshot version) > >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf-1.1/1.0.4 > >> (created for pre-release) > >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf-1.2/1.2.4 > >> (created for pre-release) > >> > >> The build/api/impl folders could be directly below these folders. Example: > >> > >> https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/jsf-1.2/trinidad-build > >> > >> Opinions? > >> > >> -Andrew > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> further stuff: > >> blog: http://matthiaswessendorf.wordpress.com/ > >> mail: matzew-at-apache-dot-org > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> further stuff: > >> blog: http://matthiaswessendorf.wordpress.com/ > >> mail: matzew-at-apache-dot-org > >> > >> > >> > >> > >> > >> > >> > > > > > > > >
