> What about supporting 1.0.x at a minimal level ? > > We can backport fixes to 1.1 on an as-needed basis with a good reason, but > over time the bar is going to rise.
that's what I was trying to say. Once the JavaEE containers are much better used / adapted, the need for JSF 1.1 won't be that large as now. To me, this makes sense. -M > > -- Blake > > > 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 > > > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
