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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- HTH, Ted. * http://www.husted.com/struts/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
