You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2006/11/26 20:38:26 UTC
Branching for Struts 1.4
Dear committers,
I would like to propose branching HEAD because of forthcoming locale
resolution strategy. I am still working on s1 with the focus of bringing
S1 to a full set of customizable internationalization capabilities.
Because the locale resolution is more powerful and may behave slightly
different (maybe), I believe it should go into 1.4 -- or rename 1.3.6 to
1.4.
This version upgrade will harmonize well with the new actionId
attribute, new I18N taglib tag attributes (dir + lang), new tags (label,
div, span), and a new DTD to reflect these attributes.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Ted Husted <hu...@apache.org>.
This began by asking for a branch. If there's reason to branch,
there's reason to release. Now, we seem to be saying there not a
reason to branch either.
There just might be a misunderstanding about when we create branches.
Typically, we just tag each milestone. Later, if we need to go back
and patch the milestone, the tag is elevated to a branch. But, it's
driven by need. Usually, we tag the milestone, and designate the HEAD
version + 0.0.1 or version + 0.1.0, and move on.
Ideally, we would assign all version labels just prior to creating a
tag. But, with nightly builds, Maven artificats, and all that, we
usually have to make a guess as to what the next tag might be.
The SNAPSHOT identifiers are all soft. We can change the POMs anytime
we want to whatever we want. Likewise with JIRA. It's just a label
that looks like a number, and we can change 1.3.6-SNAPSHOT to
1.4.0-SNAPSHOT at anytime.
Once the code is committed, then the group would be able to decide if
it's another milestone or a minor release. But there's no reason to
make the decision before then.
Though, I *STRONGLY* recommend tagging a milestone before getting off
on a new line of development. Witness what is happening with Sturts
2.0.2 now. We wanted to have a milestone every month or so, but we
didn't tag before making some brave new changes (mea culpa), and now
we can't tag because we can't get a clean build. I've seen this happen
time and again here, and we need to break the habit.
-Ted.
On 11/28/06, Paul Benedict <pb...@apache.org> wrote:
> Ted,
>
> Because no one is asking for a 1.3.6, and the new actionId feature (a
> semi-major one inmo) is already committed, can we just continue to
> develop this release and call it 1.4 afterwards? I really don't see a
> need to get this release out the door quickly. Even if 1.4 sounds too
> big of a leap to you, we can keep it at 1.3 but I'd like to get in
> everything before trying to roll another version.
>
> Paul
>
> Ted Husted wrote:
> > On 11/27/06, Paul Benedict <pb...@apache.org> wrote:
> >> Ted,
> >>
> >> Do you want the open tickets to hold up the release? Please respond. If
> >> you respond in the negative, please tag. Afterwards, I will:
> >
> > If there's a patch attached to a bug ticket, or we otherwise know how
> > to fix the bug, we should resolve those first. (The best way to get
> > more people to help is to accept help when its offered.) If some of
> > the tickets are enhancements masquerading as bugs, we should address
> > that too, so that we know where we stand.
> >
> > If we haven't a clue as how to confirm or fix an alleged bug, then the
> > only recourse is to mark it future, until someone does.
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Paul Benedict <pb...@apache.org>.
Ted,
Because no one is asking for a 1.3.6, and the new actionId feature (a
semi-major one inmo) is already committed, can we just continue to
develop this release and call it 1.4 afterwards? I really don't see a
need to get this release out the door quickly. Even if 1.4 sounds too
big of a leap to you, we can keep it at 1.3 but I'd like to get in
everything before trying to roll another version.
Paul
Ted Husted wrote:
> On 11/27/06, Paul Benedict <pb...@apache.org> wrote:
>> Ted,
>>
>> Do you want the open tickets to hold up the release? Please respond. If
>> you respond in the negative, please tag. Afterwards, I will:
>
> If there's a patch attached to a bug ticket, or we otherwise know how
> to fix the bug, we should resolve those first. (The best way to get
> more people to help is to accept help when its offered.) If some of
> the tickets are enhancements masquerading as bugs, we should address
> that too, so that we know where we stand.
>
> If we haven't a clue as how to confirm or fix an alleged bug, then the
> only recourse is to mark it future, until someone does.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Ted Husted <hu...@apache.org>.
On 11/27/06, Paul Benedict <pb...@apache.org> wrote:
> Ted,
>
> Do you want the open tickets to hold up the release? Please respond. If
> you respond in the negative, please tag. Afterwards, I will:
If there's a patch attached to a bug ticket, or we otherwise know how
to fix the bug, we should resolve those first. (The best way to get
more people to help is to accept help when its offered.) If some of
the tickets are enhancements masquerading as bugs, we should address
that too, so that we know where we stand.
If we haven't a clue as how to confirm or fix an alleged bug, then the
only recourse is to mark it future, until someone does.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/27/06, Paul Benedict <pb...@apache.org> wrote:
> Do you want the open tickets to hold up the release? Please respond. If
> you respond in the negative, please tag. Afterwards, I will:
>
> * Re-assign the open tickets to 1.3.7
> * Write the release notes
> * Update the maven projects to 1.3.7-SNAPSHOT
The release notes need to be done prior to the tag, (Ted already set
up the page,) and incrementing the version number is part of the
release process.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Paul Benedict <pb...@apache.org>.
Ted,
Do you want the open tickets to hold up the release? Please respond. If
you respond in the negative, please tag. Afterwards, I will:
* Re-assign the open tickets to 1.3.7
* Write the release notes
* Update the maven projects to 1.3.7-SNAPSHOT
Paul
Ted Husted wrote:
> In my experience, the only difficult part of a release is catching up
> the release notes. The rest is just mechanics. I'll setup a release
> notes page for Struts 1.36, and if someone wants to bring it up to
> date, I'll take care of the rest.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Ted Husted <hu...@apache.org>.
In my experience, the only difficult part of a release is catching up
the release notes. The rest is just mechanics. I'll setup a release
notes page for Struts 1.36, and if someone wants to bring it up to
date, I'll take care of the rest.
-Ted.
On 11/26/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 11/26/06, Ted Husted <hu...@apache.org> wrote:
> > My best suggestion would be to tag and roll a 1.3.6 build now, before
> > getting into a new line of development. Creating a branch would then
> > be less important.
>
> I think a 1.3.6 release goes in the 'would be nice' column. There
> were a few fixes, etc., but nothing earth shattering. I'd hate to
> divert the energy that's currently going into development, over to
> getting through our release process.
>
> So, I'd say tag the trunk as BEFORE_I18N, and carry on. We can always
> branch from that tag if we need to do another 1.3.x release. I just
> don't see that happening unless someone shows up with a serious issue.
>
> --
> Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/26/06, Ted Husted <hu...@apache.org> wrote:
> My best suggestion would be to tag and roll a 1.3.6 build now, before
> getting into a new line of development. Creating a branch would then
> be less important.
I think a 1.3.6 release goes in the 'would be nice' column. There
were a few fixes, etc., but nothing earth shattering. I'd hate to
divert the energy that's currently going into development, over to
getting through our release process.
So, I'd say tag the trunk as BEFORE_I18N, and carry on. We can always
branch from that tag if we need to do another 1.3.x release. I just
don't see that happening unless someone shows up with a serious issue.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Branching for Struts 1.4
Posted by Ted Husted <hu...@apache.org>.
My best suggestion would be to tag and roll a 1.3.6 build now, before
getting into a new line of development. Creating a branch would then
be less important.
If we did create a branch, we should give it a name (like i18n). Then,
if we find the changes joyful, the branch can be merged back into the
HEAD.
-Ted.
On 11/26/06, Paul Benedict <pb...@apache.org> wrote:
> Dear committers,
>
> I would like to propose branching HEAD because of forthcoming locale
> resolution strategy. I am still working on s1 with the focus of bringing
> S1 to a full set of customizable internationalization capabilities.
> Because the locale resolution is more powerful and may behave slightly
> different (maybe), I believe it should go into 1.4 -- or rename 1.3.6 to
> 1.4.
>
> This version upgrade will harmonize well with the new actionId
> attribute, new I18N taglib tag attributes (dir + lang), new tags (label,
> div, span), and a new DTD to reflect these attributes.
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org