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/04/15 00:50:13 UTC

[PROPOSAL] Future Releases

Here are four proposals to help us get future releases out ASAP.

1.) Branch tomahawk now (even before the core vote is finalized.) 
This will allow testing and a quick followup release since this
one-time upgrade of core will require a new tomahawk.  We release with
anything but a major show stopper.

2.) Branch core (again) immediately following the release of 1.1.2. 
The branch is several weeks old and there may already be TCK problems
in the trunk or other issues that nobody has discovered.  Since we'd
like to do more frequent releases, lets start this process earlier
rather then later.

3.) Comprehensive wiki on the release procedure starting with the core
release.  There have been so many changes and problems that I have
given up on documentation this go round.  But we should have better
documentation so that people other then myself can do the release.

4.) More TCK testers.  Get more of the committers to sign the NDA, and
more importantly, get their machines to be able to run the TCK.  The
more TCK testers we have out there the faster we can fix these
problems.

Sean

Re: [PROPOSAL] Future Releases

Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> I still think we
> always need to branch before a release so we make sure that no last
> minute problems are created by all of the ongoing work.
>   
Yes this is still required, my hope is we manage to shrink the release
cycle from weeks to a handful days.

---
Mario


Re: [PROPOSAL] Future Releases

Posted by Sean Schofield <se...@gmail.com>.
> This requires to branch share too, tomahawk head already requires stuff
> from shared head which is not in the 2.0.0 release.
> I already expressed my thoughts about this in another post: Every time
> we release core or tomahawk we have to branch shared too.

> The result will be e.g
> shared 2.0.0 for core 1.1.2
> shared 2.0.1 for tomahawk 1.1.2
> shared 2.0.2 for core 1.1.3
> and so on ....

Yes that's correct (and perfectly acceptable IMO)

> Does this mean, we have to work on the branch again if we have something
> to change/enhance?
> Then my -1 to do this, we can start the TCK on the nightly too - and fix
> the problems there, once the TCK pass and there is sufficient new stuff
> - we branch.
> IMHO this might reduce the need to merge down stuff, which is something
> (the merge down) letting me shudder.

It might be a good idea to test the latest nightly with the TCK before
branching.  That would reduce merging problems.  I still think we
always need to branch before a release so we make sure that no last
minute problems are created by all of the ongoing work.

> I dont know much about the TCK, but maybe I have a machine where we can
> setup the TCK to run on a daily - at least weekly basis.
> Intel Xeon 2.8G HT with 2GB memory. The TCK will run in an VMWare Server
> there. Should be sufficient, no?

You should sign the NDA and get on the tck list so we can discuss.

> Mario

Sean

Re: [PROPOSAL] Future Releases

Posted by Mario Ivankovits <ma...@ops.co.at>.
Sean,
> 1.) Branch tomahawk now (even before the core vote is finalized.) 
>   
This requires to branch share too, tomahawk head already requires stuff
from shared head which is not in the 2.0.0 release.
I already expressed my thoughts about this in another post: Every time
we release core or tomahawk we have to branch shared too.
The result will be e.g
shared 2.0.0 for core 1.1.2
shared 2.0.1 for tomahawk 1.1.2
shared 2.0.2 for core 1.1.3
and so on ....

> 2.) Branch core (again) immediately following the release of 1.1.2. 
>   
Does this mean, we have to work on the branch again if we have something
to change/enhance?
Then my -1 to do this, we can start the TCK on the nightly too - and fix
the problems there, once the TCK pass and there is sufficient new stuff
- we branch.
IMHO this might reduce the need to merge down stuff, which is something
(the merge down) letting me shudder.

> 4.) More TCK testers.  Get more of the committers to sign the NDA, and
> more importantly, get their machines to be able to run the TCK.  The
> more TCK testers we have out there the faster we can fix these
> problems.
>   
I dont know much about the TCK, but maybe I have a machine where we can
setup the TCK to run on a daily - at least weekly basis.
Intel Xeon 2.8G HT with 2GB memory. The TCK will run in an VMWare Server
there. Should be sufficient, no?


Ciao,
Mario