You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2007/10/24 18:51:14 UTC
[Trinidad] Create a 1.2 trunk
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
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
I am not saying, that I am -1 on two trunks. But, looking realistic to it,
I am 101% sure these two will live different lives.
Like the so called 1st world and the so call 2nd world (sorry for
using that term, but to make it clear).
So, yeah, -0.5 on two trunks :-)
-M
On 10/25/07, Jeanne Waldman <je...@oracle.com> wrote:
>
> I agree with Matthias in that I don't think we should have two trunks.
> Committing bug fixes
> to each is more hassle for more than one person, is something people that
> commit bug fixes
> will need to remember and will very easily get out of sync. It's easier for
> one person
> to merge in trunk's bug fixes with a branch.
>
> I'd prefer making 1.2 being the 'main trunk', since that is what my team
> uses.
> Can we consider that at this time? Are there more people interested in 1.2
> than 1.1?
>
> Thanks,
>
> Jeanne
>
>
> Matthias Wessendorf wrote:
> On 10/24/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
>
> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>
>
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Create a 1.2 trunk
Posted by Blake Sullivan <bl...@oracle.com>.
Matthias Wessendorf wrote:
>> 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.
>
Yep. I assume the JSF 1.1 -> 1.2 change is more painful because of the
J2EE container requirement (which hopefully JSF 2.0 will take better
advantage of than 1.2 does).
-- Blake Sullivan
> 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 <ma...@apache.org> wrote:
>>
>>
>> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
> 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 <ma...@apache.org> wrote:
>
>
> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>
>
>
>
>
>
>
>
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <Na...@gdc4s.com> 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:blake.sullivan@oracle.com]
> 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 <ma...@apache.org> wrote:
>
>
> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>
>
>
>
>
>
>
>
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Create a 1.2 trunk
Posted by Andrew Robinson <an...@gmail.com>.
> 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.
Only true if the committer decides not to update the 1.0.x branch. It
is up to the committer to decide (if we convert SVN to the new
structure that is being discussed).
This is not much different from now except for the fact that
committers are used to putting things in the trunk and ignoring 1.2.x
knowing that someone will do the merge for them.
-Andrew
RE: [Trinidad] Create a 1.2 trunk
Posted by "Perkins, Nate-P63196" <Na...@gdc4s.com>.
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:blake.sullivan@oracle.com]
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 <ma...@apache.org>
<ma...@apache.org> wrote:
On 10/24/07, Andrew Robinson
<an...@gmail.com> <ma...@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 <ma...@apache.org>
<ma...@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
<an...@gmail.com> <ma...@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
Re: [Trinidad] Create a 1.2 trunk
Posted by Blake Sullivan <bl...@oracle.com>.
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 <ma...@apache.org> wrote:
>>
>>
>> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>>
>>
>>
>>
>>
>>
>>
>
>
>
Re: [Trinidad] Create a 1.2 trunk
Posted by Andrew Robinson <an...@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 <da...@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 <ma...@apache.org> wrote:
> >>
> >>
> >> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 10/25/07, Scott O'Bryan <da...@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...
I agree.
>
> 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 <ma...@apache.org> wrote:
> >>
> >>
> >> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Create a 1.2 trunk
Posted by Scott O'Bryan <da...@gmail.com>.
+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 <ma...@apache.org> wrote:
>>
>>
>> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>>
>>
>>
>>
>>
>>
>>
>
>
>
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <ma...@apache.org> wrote:
>
>
> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>
>
>
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Create a 1.2 trunk
Posted by Blake Sullivan <bl...@oracle.com>.
Jeanne Waldman wrote:
> I agree with Matthias in that I don't think we should have two trunks.
> Committing bug fixes
> to each is more hassle for more than one person, is something people
> that commit bug fixes
> will need to remember and will very easily get out of sync. It's
> easier for one person
> to merge in trunk's bug fixes with a branch.
>
> I'd prefer making 1.2 being the 'main trunk', since that is what my
> team uses.
> Can we consider that at this time? Are there more people interested in
> 1.2 than 1.1?
>
> Thanks,
>
> Jeanne
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 <ma...@apache.org> wrote:
>>
>>> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>>>
>>>
>>
>>
>>
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 10/24/07, Matthias Wessendorf <ma...@apache.org> wrote:
> On 10/24/07, Andrew Robinson <an...@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 <ma...@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 <an...@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
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 10/24/07, Andrew Robinson <an...@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".
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 <ma...@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 <an...@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
Re: [Trinidad] Create a 1.2 trunk
Posted by Andrew Robinson <an...@gmail.com>.
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?).
Only if the feature is 1.2 specific would it be placed only on the 1.2 trunk.
This could work like:
1) work on 1.1 and optionally port to 1.2
2) apply 1.2 changes only to 1.2
3) on release, branch 1.1 and 1.2 at the same time
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)
opinions?
On 10/24/07, Matthias Wessendorf <ma...@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 <an...@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
>
Re: [Trinidad] Create a 1.2 trunk
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <an...@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