You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2006/02/17 03:42:00 UTC
New Tomahawk Branch
I just created a new tomahawk branch (retroactively) from r378399.
Martin pointed out to me that Sylvains recent checkin also depended on
a change in commons which we had already released. So in order to
avoid problems like this we'll start the branch now.
All bug fixes to tomahawk before the release should go in the branch
only until we release and then we merge down. Please don't fix in the
trunk. If the fix is too experimental for the release that's ok to
fix in the trunk then. Also new stuff like Sylvain's checkin and my
upcoming tree2 changes should go in the trunk.
We'll turn our attention to the tomahawk release next week once we
release the core.
Sean
Re: New Tomahawk Branch
Posted by Sean Schofield <se...@gmail.com>.
Interesting scenario but I don't like your conclusion. We want to get
away from forcing a releaase of all three at the same time. That was
a major goal of the maven reorg. We need to try to solve this problem
without always release all three.
Sean
On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> And that's why I still have the opinion that we cannot do other than
> release all three at the same time.
>
> Scenario:
>
> 1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2)
> 2. days go by...
> 3. We release commons-1.1.3 (because there where significant changes)
> + tomahawk 1.1.3 (which depends on commons-1.1.3)
>
> So, there are now the following official releases out there:
>
> commons-1.1.2
> commons-1.1.3
> core-1.1.2
> tomahawk-1.1.3
>
> User "happy" starts his brandnew Maven project "unlucky", decides to
> use the latest stable releases of everything and defines the following
> dependencies:
>
> XY depends on myfaces-api 1.1.2 (scope compile)
> XY depends on myfaces-impl 1.1.2 (scope runtime)
> XY depends on tomahawk 1.1.3 (scope compile)
>
> Now he builds the WAR. Guess what he ends up with?
> WEB-INF/lib/myfaces-api-1.1.2.jar
> WEB-INF/lib/myfaces-commons-1.1.2.jar
> WEB-INF/lib/myfaces-commons-1.1.3.jar
> WEB-INF/lib/myfaces-impl-1.1.2.jar
> WEB-INF/lib/myfaces-tomahawk-1.1.3.jar
>
> Not good!
>
> Ergo: We must release all 3 modules in sync.
>
> Manfred
>
>
>
>
>
>
> On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > And at some future point, we'll probably also incorporate a
> > > "repackaging" step into one of these (I'd suggest core, probably) to
> > > give the two commons versions different namespaces.
> >
> > That's what I'm attracted at more and more, too. ;-)
> >
> > Manfred
> >
>
Re: New Tomahawk Branch
Posted by Manfred Geiler <ma...@gmail.com>.
And that's why I still have the opinion that we cannot do other than
release all three at the same time.
Scenario:
1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2)
2. days go by...
3. We release commons-1.1.3 (because there where significant changes)
+ tomahawk 1.1.3 (which depends on commons-1.1.3)
So, there are now the following official releases out there:
commons-1.1.2
commons-1.1.3
core-1.1.2
tomahawk-1.1.3
User "happy" starts his brandnew Maven project "unlucky", decides to
use the latest stable releases of everything and defines the following
dependencies:
XY depends on myfaces-api 1.1.2 (scope compile)
XY depends on myfaces-impl 1.1.2 (scope runtime)
XY depends on tomahawk 1.1.3 (scope compile)
Now he builds the WAR. Guess what he ends up with?
WEB-INF/lib/myfaces-api-1.1.2.jar
WEB-INF/lib/myfaces-commons-1.1.2.jar
WEB-INF/lib/myfaces-commons-1.1.3.jar
WEB-INF/lib/myfaces-impl-1.1.2.jar
WEB-INF/lib/myfaces-tomahawk-1.1.3.jar
Not good!
Ergo: We must release all 3 modules in sync.
Manfred
On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > And at some future point, we'll probably also incorporate a
> > "repackaging" step into one of these (I'd suggest core, probably) to
> > give the two commons versions different namespaces.
>
> That's what I'm attracted at more and more, too. ;-)
>
> Manfred
>
Re: New Tomahawk Branch
Posted by Sean Schofield <se...@gmail.com>.
Good point about the TCK but I think we should handle that slightly
differently then what you are suggesting.
Why not test the TCK agains the trunk core with the branch commons?
If it passes you release commons. At that point you are not likely to
need to fix anything on the upcoming core branch that would require a
commons change. If you do, then just release commons again.
I like to get away from using release candidates. We will be able to
release faster if we just specify a project and svn revision that we
are voting on.
Sean
On 2/17/06, Bruno Aranda <br...@gmail.com> wrote:
> And what about the TCK when releasing core, it should go before any
> release (commons and core), right? If it fails due to something in
> commons we may have to fix commons. Instead of put commons directly to
> final I would change it to release candidate and only after TCK is
> passed put it final.
>
> Regards,
>
> Bruno
>
> On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > And at some future point, we'll probably also incorporate a
> > > "repackaging" step into one of these (I'd suggest core, probably) to
> > > give the two commons versions different namespaces.
> >
> > That's what I'm attracted at more and more, too. ;-)
> >
> > Manfred
> >
>
Re: New Tomahawk Branch
Posted by Bruno Aranda <br...@gmail.com>.
And what about the TCK when releasing core, it should go before any
release (commons and core), right? If it fails due to something in
commons we may have to fix commons. Instead of put commons directly to
final I would change it to release candidate and only after TCK is
passed put it final.
Regards,
Bruno
On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > And at some future point, we'll probably also incorporate a
> > "repackaging" step into one of these (I'd suggest core, probably) to
> > give the two commons versions different namespaces.
>
> That's what I'm attracted at more and more, too. ;-)
>
> Manfred
>
Re: New Tomahawk Branch
Posted by Manfred Geiler <ma...@gmail.com>.
> And at some future point, we'll probably also incorporate a
> "repackaging" step into one of these (I'd suggest core, probably) to
> give the two commons versions different namespaces.
That's what I'm attracted at more and more, too. ;-)
Manfred
Re: New Tomahawk Branch
Posted by Martin Marinschek <ma...@gmail.com>.
As long as we have all renderer bases in commons, and many of the
utility classes, commons won't have a longer release cycle than
tomahawk.
That's the practical problem!
regards,
Martin
On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> Yes, true.
> I should have said: "And that's why I still have the opinion that we
> cannot do other than
> release all three at the same time - as soon as we release a new
> commons version."
> Thanks for pointing this out, Bruno.
>
> Manfred
>
>
> On 2/17/06, Bruno Aranda <br...@gmail.com> wrote:
> > Maybe releasing commons implies releasing core and also tomahawk, but
> > releasing tomahawk, for instance, does not imply having to release
> > commons if there has not been changing in commons.
> > Commons should have longer release cycles than the other modules,
> >
> > Bruno
> >
> > On 2/17/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > > On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > And at some future point, we'll probably also incorporate a
> > > > > "repackaging" step into one of these (I'd suggest core, probably) to
> > > > > give the two commons versions different namespaces.
> > > >
> > > > What do you mean by this?
> > >
> > > It's what we've talked about before.
> > >
> > > core depending on org.myfaces.core.commons (maybe core-commons.jar)
> > > and tomahawk depending on org.myfaces.commons (maybe
> > > tomahawk-commons.jar).
> > >
> > > Thus, it's possible for core-commons.jar != tomahawk-commons.jar, and
> > > core and tomahawk can be upgraded independently of each other.
> > >
> > > Manfred's "Scenario" message in this thread shows why it's necessary
> > > for anyone who's forgotten.
> > >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: New Tomahawk Branch
Posted by Manfred Geiler <ma...@gmail.com>.
Yes, true.
I should have said: "And that's why I still have the opinion that we
cannot do other than
release all three at the same time - as soon as we release a new
commons version."
Thanks for pointing this out, Bruno.
Manfred
On 2/17/06, Bruno Aranda <br...@gmail.com> wrote:
> Maybe releasing commons implies releasing core and also tomahawk, but
> releasing tomahawk, for instance, does not imply having to release
> commons if there has not been changing in commons.
> Commons should have longer release cycles than the other modules,
>
> Bruno
>
> On 2/17/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > > > And at some future point, we'll probably also incorporate a
> > > > "repackaging" step into one of these (I'd suggest core, probably) to
> > > > give the two commons versions different namespaces.
> > >
> > > What do you mean by this?
> >
> > It's what we've talked about before.
> >
> > core depending on org.myfaces.core.commons (maybe core-commons.jar)
> > and tomahawk depending on org.myfaces.commons (maybe
> > tomahawk-commons.jar).
> >
> > Thus, it's possible for core-commons.jar != tomahawk-commons.jar, and
> > core and tomahawk can be upgraded independently of each other.
> >
> > Manfred's "Scenario" message in this thread shows why it's necessary
> > for anyone who's forgotten.
> >
>
Re: New Tomahawk Branch
Posted by Bruno Aranda <br...@gmail.com>.
Maybe releasing commons implies releasing core and also tomahawk, but
releasing tomahawk, for instance, does not imply having to release
commons if there has not been changing in commons.
Commons should have longer release cycles than the other modules,
Bruno
On 2/17/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > > And at some future point, we'll probably also incorporate a
> > > "repackaging" step into one of these (I'd suggest core, probably) to
> > > give the two commons versions different namespaces.
> >
> > What do you mean by this?
>
> It's what we've talked about before.
>
> core depending on org.myfaces.core.commons (maybe core-commons.jar)
> and tomahawk depending on org.myfaces.commons (maybe
> tomahawk-commons.jar).
>
> Thus, it's possible for core-commons.jar != tomahawk-commons.jar, and
> core and tomahawk can be upgraded independently of each other.
>
> Manfred's "Scenario" message in this thread shows why it's necessary
> for anyone who's forgotten.
>
Re: New Tomahawk Branch
Posted by Mike Kienenberger <mk...@gmail.com>.
It's probably also worth pointing out before we get too caught up in
the "doom and gloom" situation of incompatibilities that we need to
start making all commons releases backwards compatible in order for
end-users to depend upon them. That will probably eliminate many of
the issues of incompatibility between core and tomahawk.
It still leaves the possiblity of the end-user installing two
different versions of commons. Maybe we can install a phase listener
to warn the user when that happens :)
On 2/17/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > > And at some future point, we'll probably also incorporate a
> > > "repackaging" step into one of these (I'd suggest core, probably) to
> > > give the two commons versions different namespaces.
> >
> > What do you mean by this?
>
> It's what we've talked about before.
>
> core depending on org.myfaces.core.commons (maybe core-commons.jar)
> and tomahawk depending on org.myfaces.commons (maybe
> tomahawk-commons.jar).
>
> Thus, it's possible for core-commons.jar != tomahawk-commons.jar, and
> core and tomahawk can be upgraded independently of each other.
>
> Manfred's "Scenario" message in this thread shows why it's necessary
> for anyone who's forgotten.
>
Re: New Tomahawk Branch
Posted by Mike Kienenberger <mk...@gmail.com>.
On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > And at some future point, we'll probably also incorporate a
> > "repackaging" step into one of these (I'd suggest core, probably) to
> > give the two commons versions different namespaces.
>
> What do you mean by this?
It's what we've talked about before.
core depending on org.myfaces.core.commons (maybe core-commons.jar)
and tomahawk depending on org.myfaces.commons (maybe
tomahawk-commons.jar).
Thus, it's possible for core-commons.jar != tomahawk-commons.jar, and
core and tomahawk can be upgraded independently of each other.
Manfred's "Scenario" message in this thread shows why it's necessary
for anyone who's forgotten.
Re: New Tomahawk Branch
Posted by Sean Schofield <se...@gmail.com>.
> And at some future point, we'll probably also incorporate a
> "repackaging" step into one of these (I'd suggest core, probably) to
> give the two commons versions different namespaces.
What do you mean by this?
Sean
Re: New Tomahawk Branch
Posted by Mike Kienenberger <mk...@gmail.com>.
+1
Yes, I was going to suggest exactly the same thing!
And at some future point, we'll probably also incorporate a
"repackaging" step into one of these (I'd suggest core, probably) to
give the two commons versions different namespaces.
On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> After talking with Martin and Manfred I've come to realize the issue
> here. I now propose the following approach to releasing the core.
> This approach also applies to tomoahawk (just replace the word 'core'
> with 'tomahawk'.)
>
> 1.) branch commons
> 2.) branch core
> 3.) increment commons snapshot version on the trunk
> 4.) increment tomahawk snapshot version on the trunk
> 5.) test commons (branch)
> 6.) change commons snapshot version to final (on the commons branch)
> 7.) release commons
> 8.) change commons snapshot version to final (on the core branch)
> 9.) test core (branch)
> 10.) change core snapshot version to final (on the core branch)
> 11.) release core
>
> As Manfred points out, steps one and two need to be done
> simultaneously so that any changes to the upcoming core release cannot
> be affected by subsequent changes to the core trunk.
>
> The key difference in what I am proposing now is that we create only
> two branches. One for commons and one for what you're about to
> release (in this case core.) You leave the other projects (in this
> case tomahawk alone.)
>
> Then when its time to release the other project (tomahawk) you repeat
> the process. Basically you release another version of commons each
> time in order to make sure you have exactly the right code
> dependencies.
>
> Sean
>
> On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> > I didn't have time last night to address the branch fully. We just
> > need to change some refs on the branch once its made. It was on my
> > list today. I will check in soon and then tell me what you think.
> >
> > Sean
> >
> > On 2/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > I've taken some aspirine, so my headache is better now ;)
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > > The current release policy causes headache for Martin and confusion for me. ;-)
> > > >
> > > > Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
> > > > Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
> > > >
> > > > The longer I think about it, the more I'm really sure that the only
> > > > correct way to do MyFaces releases in the future is to freeze (ie.
> > > > create a branch for) all modules at the same time. Otherwise we will
> > > > always run into huge problems.
> > > > The upcoming core and tomahawk will depend on and must be compatible
> > > > to commons-1.1.2. Every current modification in core or tomahawk that
> > > > depends on commons-1.1.3-SNAPSHOT and is done in the trunk now, will
> > > > break this compatibility if we do the branch later.
> > > >
> > > > This way we could also simplify all commons dependencies by using
> > > > <dependency>
> > > > <groupId>org.apache.myfaces.commons</groupId>
> > > > <artifactId>myfaces-commons</artifactId>
> > > > <version>${version}</version>
> > > > </dependency>
> > > > instead of
> > > > <dependency>
> > > > <groupId>org.apache.myfaces.commons</groupId>
> > > > <artifactId>myfaces-commons</artifactId>
> > > > <version>1.1.3-SNAPSHOT</version>
> > > > </dependency>
> > > >
> > > > This way the release would become slightly simpler as well. These are
> > > > the necessary steps as I see them. Comments and corrections welcome!
> > > >
> > > > 1. Code freeze:
> > > > 1a. Create commons 1_1_2 branch (*)
> > > > 1b. Create core 1_1_2 branch
> > > > 1c. Create tomahawk 1_1_2 branch (*)
> > > > 2. Replace 1.1.2-SNAPSHOT by 1.1.2 in all three branches
> > > > -->Everyone is now able to install a complete 1.1.2 release in his/her
> > > > local repository by using the 1_1_2 branches
> > > > 3. Replace 1.1.2-SNAPSHOT by 1.1.3-SNAPSHOT everywhere in trunk (*)
> > > > -->Development can go on without danger for current release process
> > > > 4a. Fix citical bugs in commons branch if necessary (*)
> > > > 4b. Vote for and release commons 1.1.2 (*)
> > > > 5a. Fix citical bugs in core branch if necessary
> > > > 5b. Vote for and release core 1.1.2
> > > > 6a. Fix citical bugs in tomahawk branch if necessary
> > > > 6b. Vote for and release tomahawk 1.1.2
> > > >
> > > > (*) = already done
> > > > Order of steps 5 and 6 does not matter.
> > > >
> > > > Sean, what do you think?
> > > >
> > > > Manfred
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
>
Re: New Tomahawk Branch
Posted by Sean Schofield <se...@gmail.com>.
> You meant
> 4.) increment core snapshot version on the trunk
> instead, right?
Right. Sorry about the confusion.
> Manfred
Sean
Re: New Tomahawk Branch
Posted by Manfred Geiler <ma...@gmail.com>.
On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> After talking with Martin and Manfred I've come to realize the issue
> here. I now propose the following approach to releasing the core.
> This approach also applies to tomoahawk (just replace the word 'core'
> with 'tomahawk'.)
>
> 1.) branch commons
> 2.) branch core
> 3.) increment commons snapshot version on the trunk
> 4.) increment tomahawk snapshot version on the trunk
You meant
4.) increment core snapshot version on the trunk
instead, right?
Manfred
Re: New Tomahawk Branch
Posted by Sean Schofield <se...@gmail.com>.
After talking with Martin and Manfred I've come to realize the issue
here. I now propose the following approach to releasing the core.
This approach also applies to tomoahawk (just replace the word 'core'
with 'tomahawk'.)
1.) branch commons
2.) branch core
3.) increment commons snapshot version on the trunk
4.) increment tomahawk snapshot version on the trunk
5.) test commons (branch)
6.) change commons snapshot version to final (on the commons branch)
7.) release commons
8.) change commons snapshot version to final (on the core branch)
9.) test core (branch)
10.) change core snapshot version to final (on the core branch)
11.) release core
As Manfred points out, steps one and two need to be done
simultaneously so that any changes to the upcoming core release cannot
be affected by subsequent changes to the core trunk.
The key difference in what I am proposing now is that we create only
two branches. One for commons and one for what you're about to
release (in this case core.) You leave the other projects (in this
case tomahawk alone.)
Then when its time to release the other project (tomahawk) you repeat
the process. Basically you release another version of commons each
time in order to make sure you have exactly the right code
dependencies.
Sean
On 2/17/06, Sean Schofield <se...@gmail.com> wrote:
> I didn't have time last night to address the branch fully. We just
> need to change some refs on the branch once its made. It was on my
> list today. I will check in soon and then tell me what you think.
>
> Sean
>
> On 2/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> > I've taken some aspirine, so my headache is better now ;)
> >
> > regards,
> >
> > Martin
> >
> > On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > > The current release policy causes headache for Martin and confusion for me. ;-)
> > >
> > > Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
> > > Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
> > >
> > > The longer I think about it, the more I'm really sure that the only
> > > correct way to do MyFaces releases in the future is to freeze (ie.
> > > create a branch for) all modules at the same time. Otherwise we will
> > > always run into huge problems.
> > > The upcoming core and tomahawk will depend on and must be compatible
> > > to commons-1.1.2. Every current modification in core or tomahawk that
> > > depends on commons-1.1.3-SNAPSHOT and is done in the trunk now, will
> > > break this compatibility if we do the branch later.
> > >
> > > This way we could also simplify all commons dependencies by using
> > > <dependency>
> > > <groupId>org.apache.myfaces.commons</groupId>
> > > <artifactId>myfaces-commons</artifactId>
> > > <version>${version}</version>
> > > </dependency>
> > > instead of
> > > <dependency>
> > > <groupId>org.apache.myfaces.commons</groupId>
> > > <artifactId>myfaces-commons</artifactId>
> > > <version>1.1.3-SNAPSHOT</version>
> > > </dependency>
> > >
> > > This way the release would become slightly simpler as well. These are
> > > the necessary steps as I see them. Comments and corrections welcome!
> > >
> > > 1. Code freeze:
> > > 1a. Create commons 1_1_2 branch (*)
> > > 1b. Create core 1_1_2 branch
> > > 1c. Create tomahawk 1_1_2 branch (*)
> > > 2. Replace 1.1.2-SNAPSHOT by 1.1.2 in all three branches
> > > -->Everyone is now able to install a complete 1.1.2 release in his/her
> > > local repository by using the 1_1_2 branches
> > > 3. Replace 1.1.2-SNAPSHOT by 1.1.3-SNAPSHOT everywhere in trunk (*)
> > > -->Development can go on without danger for current release process
> > > 4a. Fix citical bugs in commons branch if necessary (*)
> > > 4b. Vote for and release commons 1.1.2 (*)
> > > 5a. Fix citical bugs in core branch if necessary
> > > 5b. Vote for and release core 1.1.2
> > > 6a. Fix citical bugs in tomahawk branch if necessary
> > > 6b. Vote for and release tomahawk 1.1.2
> > >
> > > (*) = already done
> > > Order of steps 5 and 6 does not matter.
> > >
> > > Sean, what do you think?
> > >
> > > Manfred
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
Re: New Tomahawk Branch
Posted by Sean Schofield <se...@gmail.com>.
I didn't have time last night to address the branch fully. We just
need to change some refs on the branch once its made. It was on my
list today. I will check in soon and then tell me what you think.
Sean
On 2/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> I've taken some aspirine, so my headache is better now ;)
>
> regards,
>
> Martin
>
> On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> > The current release policy causes headache for Martin and confusion for me. ;-)
> >
> > Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
> > Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
> >
> > The longer I think about it, the more I'm really sure that the only
> > correct way to do MyFaces releases in the future is to freeze (ie.
> > create a branch for) all modules at the same time. Otherwise we will
> > always run into huge problems.
> > The upcoming core and tomahawk will depend on and must be compatible
> > to commons-1.1.2. Every current modification in core or tomahawk that
> > depends on commons-1.1.3-SNAPSHOT and is done in the trunk now, will
> > break this compatibility if we do the branch later.
> >
> > This way we could also simplify all commons dependencies by using
> > <dependency>
> > <groupId>org.apache.myfaces.commons</groupId>
> > <artifactId>myfaces-commons</artifactId>
> > <version>${version}</version>
> > </dependency>
> > instead of
> > <dependency>
> > <groupId>org.apache.myfaces.commons</groupId>
> > <artifactId>myfaces-commons</artifactId>
> > <version>1.1.3-SNAPSHOT</version>
> > </dependency>
> >
> > This way the release would become slightly simpler as well. These are
> > the necessary steps as I see them. Comments and corrections welcome!
> >
> > 1. Code freeze:
> > 1a. Create commons 1_1_2 branch (*)
> > 1b. Create core 1_1_2 branch
> > 1c. Create tomahawk 1_1_2 branch (*)
> > 2. Replace 1.1.2-SNAPSHOT by 1.1.2 in all three branches
> > -->Everyone is now able to install a complete 1.1.2 release in his/her
> > local repository by using the 1_1_2 branches
> > 3. Replace 1.1.2-SNAPSHOT by 1.1.3-SNAPSHOT everywhere in trunk (*)
> > -->Development can go on without danger for current release process
> > 4a. Fix citical bugs in commons branch if necessary (*)
> > 4b. Vote for and release commons 1.1.2 (*)
> > 5a. Fix citical bugs in core branch if necessary
> > 5b. Vote for and release core 1.1.2
> > 6a. Fix citical bugs in tomahawk branch if necessary
> > 6b. Vote for and release tomahawk 1.1.2
> >
> > (*) = already done
> > Order of steps 5 and 6 does not matter.
> >
> > Sean, what do you think?
> >
> > Manfred
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: New Tomahawk Branch
Posted by Martin Marinschek <ma...@gmail.com>.
I've taken some aspirine, so my headache is better now ;)
regards,
Martin
On 2/17/06, Manfred Geiler <ma...@gmail.com> wrote:
> The current release policy causes headache for Martin and confusion for me. ;-)
>
> Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
> Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
>
> The longer I think about it, the more I'm really sure that the only
> correct way to do MyFaces releases in the future is to freeze (ie.
> create a branch for) all modules at the same time. Otherwise we will
> always run into huge problems.
> The upcoming core and tomahawk will depend on and must be compatible
> to commons-1.1.2. Every current modification in core or tomahawk that
> depends on commons-1.1.3-SNAPSHOT and is done in the trunk now, will
> break this compatibility if we do the branch later.
>
> This way we could also simplify all commons dependencies by using
> <dependency>
> <groupId>org.apache.myfaces.commons</groupId>
> <artifactId>myfaces-commons</artifactId>
> <version>${version}</version>
> </dependency>
> instead of
> <dependency>
> <groupId>org.apache.myfaces.commons</groupId>
> <artifactId>myfaces-commons</artifactId>
> <version>1.1.3-SNAPSHOT</version>
> </dependency>
>
> This way the release would become slightly simpler as well. These are
> the necessary steps as I see them. Comments and corrections welcome!
>
> 1. Code freeze:
> 1a. Create commons 1_1_2 branch (*)
> 1b. Create core 1_1_2 branch
> 1c. Create tomahawk 1_1_2 branch (*)
> 2. Replace 1.1.2-SNAPSHOT by 1.1.2 in all three branches
> -->Everyone is now able to install a complete 1.1.2 release in his/her
> local repository by using the 1_1_2 branches
> 3. Replace 1.1.2-SNAPSHOT by 1.1.3-SNAPSHOT everywhere in trunk (*)
> -->Development can go on without danger for current release process
> 4a. Fix citical bugs in commons branch if necessary (*)
> 4b. Vote for and release commons 1.1.2 (*)
> 5a. Fix citical bugs in core branch if necessary
> 5b. Vote for and release core 1.1.2
> 6a. Fix citical bugs in tomahawk branch if necessary
> 6b. Vote for and release tomahawk 1.1.2
>
> (*) = already done
> Order of steps 5 and 6 does not matter.
>
> Sean, what do you think?
>
> Manfred
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: New Tomahawk Branch
Posted by Manfred Geiler <ma...@gmail.com>.
The current release policy causes headache for Martin and confusion for me. ;-)
Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
The longer I think about it, the more I'm really sure that the only
correct way to do MyFaces releases in the future is to freeze (ie.
create a branch for) all modules at the same time. Otherwise we will
always run into huge problems.
The upcoming core and tomahawk will depend on and must be compatible
to commons-1.1.2. Every current modification in core or tomahawk that
depends on commons-1.1.3-SNAPSHOT and is done in the trunk now, will
break this compatibility if we do the branch later.
This way we could also simplify all commons dependencies by using
<dependency>
<groupId>org.apache.myfaces.commons</groupId>
<artifactId>myfaces-commons</artifactId>
<version>${version}</version>
</dependency>
instead of
<dependency>
<groupId>org.apache.myfaces.commons</groupId>
<artifactId>myfaces-commons</artifactId>
<version>1.1.3-SNAPSHOT</version>
</dependency>
This way the release would become slightly simpler as well. These are
the necessary steps as I see them. Comments and corrections welcome!
1. Code freeze:
1a. Create commons 1_1_2 branch (*)
1b. Create core 1_1_2 branch
1c. Create tomahawk 1_1_2 branch (*)
2. Replace 1.1.2-SNAPSHOT by 1.1.2 in all three branches
-->Everyone is now able to install a complete 1.1.2 release in his/her
local repository by using the 1_1_2 branches
3. Replace 1.1.2-SNAPSHOT by 1.1.3-SNAPSHOT everywhere in trunk (*)
-->Development can go on without danger for current release process
4a. Fix citical bugs in commons branch if necessary (*)
4b. Vote for and release commons 1.1.2 (*)
5a. Fix citical bugs in core branch if necessary
5b. Vote for and release core 1.1.2
6a. Fix citical bugs in tomahawk branch if necessary
6b. Vote for and release tomahawk 1.1.2
(*) = already done
Order of steps 5 and 6 does not matter.
Sean, what do you think?
Manfred