You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Rahul Akolkar <ra...@gmail.com> on 2007/01/01 21:56:14 UTC
Code freeze 1.0.x branch
The SHALE_1_0_X branch [1] has been created. Over the next day, it
will be used to prepare the proposed v1.0.4 artifacts and svn tag.
My preference would be to have no commits to the branch when releases
are being prepared and voted on (relevant commits to trunk that need
to be backported can wait a day or two, unless its a showstopper for
the release). I will ping this thread when this is done for v1.0.4,
and the branch is open for general commits.
-Rahul
[1] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
Re: Code freeze 1.0.x branch
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/1/07, Craig McClanahan <cr...@apache.org> wrote:
> On 1/1/07, Rahul Akolkar <ra...@gmail.com> wrote:
<snip/>
> >
> > More generally, I propose we have the following procedure for future
> > releases:
> >
> > (1) At the appropriate time, the RM declares a code freeze on the
> > relevant branch
> > (2) Development continues in all other branches, and developers keep
> > notes of any changes that need to be ported to the "frozen" branch
> > (3) When freeze is over, developers commit pending changes
> >
> > Showstoppers that require a fix to the frozen branch restart the process
> > at (1).
>
>
> Sounds like a good general policy, although I suspect there generally will
> *not* be pending changes that we did not already discuss and decide on --
> it will probably amount to a few patches that were deemed not critical to
> getting a maintenance release out the door. But time will tell :-).
>
<snap/>
Agreed :-)
> In the mean time, I'll go ahead and update the trunk version numbers to
> 1.1.0-SNAPSHOT, per our previous discussions. I've also added a JIRA
> version for this, so we can start tagging issues for new development as they
> get dealt with there.
>
<snip/>
Sounds good, thanks.
-Rahul
>
> Craig
>
>
Re: Code freeze 1.0.x branch
Posted by Craig McClanahan <cr...@apache.org>.
On 1/1/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 1/1/07, Craig McClanahan <cr...@apache.org> wrote:
> > On 1/1/07, Rahul Akolkar <ra...@gmail.com> wrote:
> > >
> > > The SHALE_1_0_X branch [1] has been created. Over the next day, it
> > > will be used to prepare the proposed v1.0.4 artifacts and svn tag.
> > >
> > > My preference would be to have no commits to the branch when releases
> > > are being prepared and voted on (relevant commits to trunk that need
> > > to be backported can wait a day or two, unless its a showstopper for
> > > the release). I will ping this thread when this is done for v1.0.4,
> > > and the branch is open for general commits.
> >
> >
> > Does this also imply that the trunk is now open for new features? I
> want to
> > spend a bit of time between plays :-) on things like SHALE-262, and it'd
> be
> > easier to just work on the trunk now, rather than branching shale-test
> and
> > then merging later.
> >
> <snip/>
>
> Indeed, now that we have multiple lines of development, development
> need not stop just because a release is imminent. The v104 tag will
> come from the 10x branch, so the trunk is no longer relevant for the
> release ;-)
>
> More generally, I propose we have the following procedure for future
> releases:
>
> (1) At the appropriate time, the RM declares a code freeze on the
> relevant branch
> (2) Development continues in all other branches, and developers keep
> notes of any changes that need to be ported to the "frozen" branch
> (3) When freeze is over, developers commit pending changes
>
> Showstoppers that require a fix to the frozen branch restart the process
> at (1).
Sounds like a good general policy, although I suspect there generally will
*not* be pending changes that we did not already discuss and decide on --
it will probably amount to a few patches that were deemed not critical to
getting a maintenance release out the door. But time will tell :-).
In the mean time, I'll go ahead and update the trunk version numbers to
1.1.0-SNAPSHOT, per our previous discussions. I've also added a JIRA
version for this, so we can start tagging issues for new development as they
get dealt with there.
-Rahul
Craig
> (And no, I'm *not* going to propose that we add a new feature to 1.0.4 at
> > the last minute :-).
> >
> > Craig
> >
> >
> > -Rahul
> > >
> > > [1]
> http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
> > >
> >
> >
>
Re: Code freeze 1.0.x branch
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/1/07, Craig McClanahan <cr...@apache.org> wrote:
> On 1/1/07, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > The SHALE_1_0_X branch [1] has been created. Over the next day, it
> > will be used to prepare the proposed v1.0.4 artifacts and svn tag.
> >
> > My preference would be to have no commits to the branch when releases
> > are being prepared and voted on (relevant commits to trunk that need
> > to be backported can wait a day or two, unless its a showstopper for
> > the release). I will ping this thread when this is done for v1.0.4,
> > and the branch is open for general commits.
>
>
> Does this also imply that the trunk is now open for new features? I want to
> spend a bit of time between plays :-) on things like SHALE-262, and it'd be
> easier to just work on the trunk now, rather than branching shale-test and
> then merging later.
>
<snip/>
Indeed, now that we have multiple lines of development, development
need not stop just because a release is imminent. The v104 tag will
come from the 10x branch, so the trunk is no longer relevant for the
release ;-)
More generally, I propose we have the following procedure for future releases:
(1) At the appropriate time, the RM declares a code freeze on the
relevant branch
(2) Development continues in all other branches, and developers keep
notes of any changes that need to be ported to the "frozen" branch
(3) When freeze is over, developers commit pending changes
Showstoppers that require a fix to the frozen branch restart the process at (1).
-Rahul
> (And no, I'm *not* going to propose that we add a new feature to 1.0.4 at
> the last minute :-).
>
> Craig
>
>
> -Rahul
> >
> > [1] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
> >
>
>
Re: Code freeze 1.0.x branch
Posted by Craig McClanahan <cr...@apache.org>.
On 1/1/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> The SHALE_1_0_X branch [1] has been created. Over the next day, it
> will be used to prepare the proposed v1.0.4 artifacts and svn tag.
>
> My preference would be to have no commits to the branch when releases
> are being prepared and voted on (relevant commits to trunk that need
> to be backported can wait a day or two, unless its a showstopper for
> the release). I will ping this thread when this is done for v1.0.4,
> and the branch is open for general commits.
Does this also imply that the trunk is now open for new features? I want to
spend a bit of time between plays :-) on things like SHALE-262, and it'd be
easier to just work on the trunk now, rather than branching shale-test and
then merging later.
(And no, I'm *not* going to propose that we add a new feature to 1.0.4 at
the last minute :-).
Craig
-Rahul
>
> [1] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
>