Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of andrew.rw.robinson@gmail.com
 designates 209.85.198.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=SP1abDMHiaNNW5C9r/ExXceJUe3exmu7/Vr2HERAMchgSv+zGFBHdN9MWV8WsnztXmSQ+zSBf9y4WUTfRb/p1+gv8nXqxNjuF0nIZxi42j9W5lATqPxOiEzr3rD4t3ZeNuNO77fGoJewTMiHwcQdmjoMagYXul0MWGbhkHawWhk=
Message-ID: <bc36a6210710251041t7fd9e940vd9523fc3657a87b7@mail.gmail.com>
Date: Thu, 25 Oct 2007 11:41:17 -0600
From: "Andrew Robinson" <andrew.rw.robinson@gmail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: [Trinidad] Create a 1.2 trunk
In-Reply-To: <4720D36C.30102@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bc36a6210710240951g753cc793g471b6a62cba4992f@mail.gmail.com>
	 <71235db40710240958o5a183615sdb7936a0de92bf55@mail.gmail.com>
	 <bc36a6210710241015o289cb161h6455195790f8bbb0@mail.gmail.com>
	 <71235db40710241030u52b402c7k33122ce5c9844bd9@mail.gmail.com>
	 <71235db40710241057w69e23125j1e4b43309e96d4e4@mail.gmail.com>
	 <4720BDD8.50200@oracle.com> <4720CBB9.4000902@oracle.com>
	 <71235db40710251023j6de43b19wee06c279eaf72611@mail.gmail.com>
	 <4720D36C.30102@gmail.com>

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 <darkarena@gmail.com> 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 <matzew@apache.org> wrote:
> >>
> >>
> >>  On 10/24/07, Andrew Robinson <andrew.rw.robinson@gmail.com> 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 <matzew@apache.org> 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 <andrew.rw.robinson@gmail.com> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>