No, I don't think that this sounds like give up on 1.0.x users. I personally think that a) two "main" trunks are to much to maintain b) the future will be JSF 2, but between that and now JSF 1.2 will come more and more in to the game, at least because of the Java EE containers just ship an impl.
-Matthias On 10/25/07, Perkins, Nate-P63196 <[EMAIL PROTECTED]> wrote: > > > The impression that this chain is giving off is that if certain Trinidad > users are bound by requirements to 1.0.* that they will be basically out of > luck for new features and bug fixes. > > > Nate Perkins > General Dynamics C4 Systems > > This email message is for the sole use of the intended recipient(s) and may > contain GDC4S > confidential or privileged information. Any unauthorized review, use, > disclosure or distribution > is prohibited. If you are not an intended recipient, please contact the > sender by reply email and > destroy all copies of the original message. > > > ________________________________ > From: Blake Sullivan [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 25, 2007 10:41 AM > To: MyFaces Development > Subject: Re: [Trinidad] Create a 1.2 trunk > > > 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 ? > > 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. > > -- 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
