releases

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

releases

steven_parkes
A question about releases, mostly with respect to Jira, I guess.

There a number of resolved Jira issues that spec the Fix Version/s as
2.0.1. I'm wondering if I'm interpreting this correctly: to me, this
would mean that the changes have been checked into branches/lucene_2_0,
not trunk. But these were actually checked into trunk. As far as the
changes go, that's what I expect. Unless there's a great demand for it
(like some horrendous security bug), I don't expect there ever will be a
2.0.1. But as far as Jira resolved issues goes, Fix Version/s 2.0.1
should mean checked into branches/lucene_2_0 and Fix Version/s 2.1
should mean checked into trunk (until there is a 2.1 release)?




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Chris Hostetter-3

: There a number of resolved Jira issues that spec the Fix Version/s as
: 2.0.1. I'm wondering if I'm interpreting this correctly: to me, this
: would mean that the changes have been checked into branches/lucene_2_0,
: not trunk. But these were actually checked into trunk. As far as the

I believe the method used in the past is that code is only ever commited
onto the trunk, and the Fix Version denotes what hypothetical version the
committer feels the issue is important enough to be released in.  Looking
at a list of all bugs marked "2.0.1" should give you an indication of what
code has been commited that people feel needs to be inlcuded in a 2.0.1
release, if/when a 2.0.1 release is made, those patches would be merged
from the trunk to the 2_0 branch.

Doug touched on this briefly here...

http://www.nabble.com/jira-workflow-tf2459130.html#a6860450

...there was a more in depth discussion about it back when 1.9/2.0 were
being planned,b ut i can't find it now.

I can't say for certain that people have been using Fix Version
consistently in that maner however.


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Otis Gospodnetic-2
In reply to this post by steven_parkes
Steven,

I don't recall any commits in the lucene_2_0 branch, I think everything since 2.0 has been getting committed in the trunk, and my guess is those are just human errors in JIRA.  But I think your interpretation of how Fix Versions should be read is correct.

Otis

----- Original Message ----
From: Steven Parkes <[hidden email]>
To: [hidden email]
Sent: Wednesday, October 25, 2006 1:41:05 PM
Subject: releases

A question about releases, mostly with respect to Jira, I guess.

There a number of resolved Jira issues that spec the Fix Version/s as
2.0.1. I'm wondering if I'm interpreting this correctly: to me, this
would mean that the changes have been checked into branches/lucene_2_0,
not trunk. But these were actually checked into trunk. As far as the
changes go, that's what I expect. Unless there's a great demand for it
(like some horrendous security bug), I don't expect there ever will be a
2.0.1. But as far as Jira resolved issues goes, Fix Version/s 2.0.1
should mean checked into branches/lucene_2_0 and Fix Version/s 2.1
should mean checked into trunk (until there is a 2.1 release)?




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Chris Hostetter-3

: I don't recall any commits in the lucene_2_0 branch, I think everything
: since 2.0 has been getting committed in the trunk, and my guess is those
: are just human errors in JIRA.  But I think your interpretation of how
: Fix Versions should be read is correct.

this is the past thread i was thinking about before...

http://www.archivum.info/java-dev@.../2006-06/msg00012.html

...refering to leaving the release branches clean untill just before a
point release when all the desired changes can get merged in.

allthough now i'm more confused about how exactly "Fix Version" should be
used ... Doug seemed to be advocating one usage in that htread, and a
differnet usage in the more recent thread.

it seems like we really need a wiki on how we *want* to use the various
fields in Jira (assignee, "New", "Pathc available", "Fix Version", etc...)


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Doug Cutting
Chris Hostetter wrote:
> this is the past thread i was thinking about before...
>
> http://www.archivum.info/java-dev@.../2006-06/msg00012.html
>
> ...refering to leaving the release branches clean untill just before a
> point release when all the desired changes can get merged in.

That's the way I find it easiest to manage.  Otherwise you have to
remember which patches have been applied to the branch and which have
not.  So I prefer to merge them to the branch them all-at-once.  However
if the branch diverges from trunk much then that's impractical.

> allthough now i'm more confused about how exactly "Fix Version" should be
> used ... Doug seemed to be advocating one usage in that htread, and a
> differnet usage in the more recent thread.

Fix Version should name the first release that the patch is intended to
appear in.  This may or may not correspond directly to the subversion
branch that the patch is committed to.

Another approach is to make all patches first in the release branch,
then merge them to trunk.  Personally I find that to be a pain, but it
might be more scalable.  It keeps things synchronized between Jira and
subversion.

> it seems like we really need a wiki on how we *want* to use the various
> fields in Jira (assignee, "New", "Pathc available", "Fix Version", etc...)

+1

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

steven_parkes
In reply to this post by steven_parkes
        Another approach is to make all patches first in the release
branch,
        then merge them to trunk.  Personally I find that to be a pain,

A royal pain, I agree. And very, very possibly a waste of time, since
there may never be a 2.0.1 release.

I think a lot comes down to the thinking around patch releases and I
don't know how the Lucene community has handled this. There are number
of different approaches, all of which have their plusses and minuses.

  but it
        might be more scalable.  It keeps things synchronized between
Jira and
        subversion.

This is the part that I like (synchronization) and find valuable. But
the alternative to checking into both branches and flagging as both (or
the bug fix branch only?) is to flag everything as (for example), 2.1
and nothing as 2.0.1 until a decision is made to actually create a
2.0.1.

I guess I figure the process for 2.0.1, if there was a compelling need
for it, would be to review all the changes that have happened since 2.0
was cut. Were I to do this, I'd look at the ones flagged as 2.1 as well
as the 2.0.1, so I don't see that flagging early really buys much.

Flagging something for 2.0.1 now seems of limited value, too. It's a
balance, right, deciding which patches would go in? In particular, not
only is the value of the patch at issue, but also the pain of applying
it. At this point, a lot of stuff has gone into trunk and a bug fix
patch may have dependences on other stuff. I figure one would have to
see a patch as compelling to the degree that the dependences were
difficult to unknotting. And I figure someone flagging something as
2.0.1 now isn't going to spend the time to figure all that stuff out. I
wouldn't, since I don't know if there ever will be a 2.0.1.

On the other hand, I like the idea of being able to look at the list of
resolved issues and see the Fix Version/s to tell me where they've been
checked in. And this ties into Jira's release notes thing. Or even the
change log. If there were a 2.0.1 release and then a 2.1 release, what
would the change log and release notes for 2.1 be relative to? I don't
really like the idea of mucking with the trunk change log when the
(putative) 2.0.1 release is made so that the change log groups things to
show differences between 2.1 and 2.0.1 (instead of 2.1 and 2.0, which is
what it has now). If that's the case, that 2.1 is relative to 2.0, then
no issue should be flagged only a patch release, but a main release and
one or more patch releases.

But that's wrong, too. Sometimes bugs exist on a patch branch that don't
exist on the trunk, which would mean that if Jira FVs is really going to
reflect reality, 2.0.1 can't implicitly imply 2.1, since that might not
always be the case.

Of course, all this can happen at release time, for both patch and main
releases. I don't think the flagging approach (flag only main release
vs. flag only patch release (vs. flag both?)) results in differences in
Fix Version/s on closed issues.

But consistency would help me and I suppose I still favor flagging
everything as 2.1 now. If not for the simple reason that I don't know
how to decide if something should go into some 2.0.1 when I don't know
what's going to trigger the need for it.

I kinda feel like I should apologize for belaboring all this but I got
people that want answers to these questions. I'll right up the wiki
summary.

-----Original Message-----
From: Doug Cutting [mailto:[hidden email]]
Sent: Thursday, October 26, 2006 12:28 PM
To: [hidden email]
Subject: Re: releases

Chris Hostetter wrote:
> this is the past thread i was thinking about before...
>
>
http://www.archivum.info/java-dev@.../2006-06/msg00012.htm
l
>
> ...refering to leaving the release branches clean untill just before a
> point release when all the desired changes can get merged in.

That's the way I find it easiest to manage.  Otherwise you have to
remember which patches have been applied to the branch and which have
not.  So I prefer to merge them to the branch them all-at-once.  However

if the branch diverges from trunk much then that's impractical.

> allthough now i'm more confused about how exactly "Fix Version" should
be
> used ... Doug seemed to be advocating one usage in that htread, and a
> differnet usage in the more recent thread.

Fix Version should name the first release that the patch is intended to
appear in.  This may or may not correspond directly to the subversion
branch that the patch is committed to.

Another approach is to make all patches first in the release branch,
then merge them to trunk.  Personally I find that to be a pain, but it
might be more scalable.  It keeps things synchronized between Jira and
subversion.

> it seems like we really need a wiki on how we *want* to use the
various
> fields in Jira (assignee, "New", "Pathc available", "Fix Version",
etc...)

+1

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

Chris Hostetter-3

: I guess I figure the process for 2.0.1, if there was a compelling need
: for it, would be to review all the changes that have happened since 2.0
: was cut. Were I to do this, I'd look at the ones flagged as 2.1 as well
: as the 2.0.1, so I don't see that flagging early really buys much.

It's kind of a chicken/egg problem ... either releases are scheduled, and
the Fix Version can be used by the committers to denote to the release
manager(s): "Issue A is a bug fix and adds no new functionality, so it
should go in 2.0.1 when/if it's created.  Issue B is new functionality
that changes no existing APIs so it should wait for 2.1, Issue C
changes existing APIs so it should wait for 3.0" ...and hte release
managers just merge the changes with teh appropriate flag into the lreease
branch.
   ...OR...
release are driven by need, and someone looks at the list of
resolved issues and their flags and either says either "hmmm, looks like
we should make a 2.0.1 release" or "hmm, not a lot of need for a 2.0.1
release, but we seem to have plenty of stuff to warrant a 2.1 release."

: Flagging something for 2.0.1 now seems of limited value, too. It's a
: balance, right, deciding which patches would go in? In particular, not
: only is the value of the patch at issue, but also the pain of applying
: it. At this point, a lot of stuff has gone into trunk and a bug fix
: patch may have dependences on other stuff. I figure one would have to
: see a patch as compelling to the degree that the dependences were
: difficult to unknotting. And I figure someone flagging something as
: 2.0.1 now isn't going to spend the time to figure all that stuff out. I
: wouldn't, since I don't know if there ever will be a 2.0.1.

it's not really about flagging a patch as being 2.0.1 worthy ... it's
indicating that the issue is 2.0.1 worthy ... the "fix" for a 2.0.1
release branch might be completely different from what is done in the
trunk.

: change log. If there were a 2.0.1 release and then a 2.1 release, what
: would the change log and release notes for 2.1 be relative to? I don't

they would be relative 2.0 ... the 2.0.1 additions to the notes wouldn't
be there becuase they would be on the 2.0 release branch.

: But consistency would help me and I suppose I still favor flagging
: everything as 2.1 now. If not for the simple reason that I don't know
: how to decide if something should go into some 2.0.1 when I don't know
: what's going to trigger the need for it.

see ... i would argue that it makes more sense to just leave FV
unspecified unless you have a specific reason why you think the issue you
are resolving should *drive* the creation of a release, or be merged into
a specific release branch.  Only if you are saying "this is an urgent bug
fix" should you flag something as 2.0.1 indicating that you think we need
a 2.0.1 release.

: I kinda feel like I should apologize for belaboring all this but I got
: people that want answers to these questions. I'll right up the wiki
: summary.

It's good to hash these issues out ... we do need better documentation so
that people "discovering" Lucene have a way to make sense of both Jira and
the release process/plan



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

steven_parkes
In reply to this post by steven_parkes
I've been thinking this all through and I guess my question is with the
synchronization between Jira and svn. The fact that Resolved/Fixed is
usually tied to a commit shows we all think they are related: we're all
using Jira to reflect svn to some extent, right?

I'd like to be able to look at Jira and know if a fix for an issue has
been committed to a particular branch. I had thought that's what Fix
Version/s meant, though I see that's not exactly it.

And an observation: shouldn't everything currently in Resolved have a
FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since
it's already committed to trunk, it's obviously planned to be fixed in
2.1, right?

What about adding a Committed field? Looking at the docs, it should be
possible. I'm actually more interested in that field then I am in FVs,
if not simply because it's a lot less ambiguous and subjective. I don't
need to know the release process to interpret it.

I think it could facilitate some things, should we ever want to. I
wonder how the RM handles making patch releases. If it were me, tasked
with making a 2.0.1 release (should that be decided) and it was decided
to have a lot of the patches in, my to-do list would be all those issues
that have FV with 2.0.1 and did not have Committed with 2.0.1. Then I'd
update the Jira issues as I did the merges. If it's really a simple
release, it might be overkill but as soon as it gets a little
complicated, it seems like the tracking would be really handy.

Overkill? If a description of how we are supposed to be using AVs and
FVs had existed before I started, I'd probably never have even thought
about it this much. But having thought of it, I'm actually still in
favor of it. I really like the idea of being able to go to Jira and know
which branches had fixes committed on them.

?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Otis Gospodnetic-2
In reply to this post by steven_parkes
----- Original Message ----
From: Chris Hostetter <[hidden email]>

: But consistency would help me and I suppose I still favor flagging
: everything as 2.1 now. If not for the simple reason that I don't know
: how to decide if something should go into some 2.0.1 when I don't know
: what's going to trigger the need for it.

see ... i would argue that it makes more sense to just leave FV
unspecified unless you have a specific reason why you think the issue you
are resolving should *drive* the creation of a release, or be merged into
a specific release branch.  Only if you are saying "this is an urgent bug
fix" should you flag something as 2.0.1 indicating that you think we need
a 2.0.1 release.

OG: I agree.  I think historically we've had only a few point (X.Y.Z) releases due to serious bugs.  Check page 9 in Lucene in Action for release history up to 1.4.3.  It looks like 1.4.1 was the only bug-caused point release.  In general, I think patches have been going to trunk, and we'd just pick a day to make a release when enough new stuff/fixes accumulated.  If what I'm saying is right, then I think what Hoss is saying makes sense - leave FV unspecified, unless the patch is for a serious bug that needs to be applied to the released version and another release be made.

Otis




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Otis Gospodnetic-2
In reply to this post by steven_parkes
Hi,

----- Original Message ----
From: Steven Parkes <[hidden email]>

And an observation: shouldn't everything currently in Resolved have a
FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since

OG: I never specify FV.  I bet you will see most issues in Resolved state have no FV.

it's already committed to trunk, it's obviously planned to be fixed in 2.1, right?

OG: right.  We don't know when 2.1 will happen, we don't know wha exactly will be in it, but we do know there will be 2.1.

What about adding a Committed field? Looking at the docs, it should be
possible. I'm actually more interested in that field then I am in FVs,
if not simply because it's a lot less ambiguous and subjective. I don't
need to know the release process to interpret it.

OG: what would that be used for?  Personally, I'm for not going crazy with additions of a bunch of new fields - the more I have to think while working with JIRA, the more I'm going to avoid it. :)

I think it could facilitate some things, should we ever want to. I
wonder how the RM handles making patch releases. If it were me, tasked

OG: Ronald McDonald?  I think the only person who actually rolled a release around here is Doug.  The rest of us are just theorizing.... but somebody's got to do that.

with making a 2.0.1 release (should that be decided) and it was decided
to have a lot of the patches in, my to-do list would be all those issues
that have FV with 2.0.1 and did not have Committed with 2.0.1. Then I'd
update the Jira issues as I did the merges. If it's really a simple
release, it might be overkill but as soon as it gets a little
complicated, it seems like the tracking would be really handy.

Otis





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

Chris Hostetter-3
In reply to this post by steven_parkes

: And an observation: shouldn't everything currently in Resolved have a
: FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since
: it's already committed to trunk, it's obviously planned to be fixed in
: 2.1, right?

not neccessarily ... if somethings in the trunk, you're saying it should
be included in a release eventually ... but that doesn't neccessarily need
ot be the 2.1 release ,it might be the 3.0 release ... Fieldable is a good
example of something where a significant API change was made, should that
really got in a 21 release? ... maybe, but it's not clear.

if something is marked FV 2.1 then that indicates that it *should* be in
2.1 if/when 2.1 is released ... no FV means there is no set opinion on
when it should be released.

: What about adding a Committed field? Looking at the docs, it should be
: possible. I'm actually more interested in that field then I am in FVs,
: if not simply because it's a lot less ambiguous and subjective. I don't
: need to know the release process to interpret it.

i think what you are describing is really waht the intended purpose of FV
is ... so that people browsing Jira can see "oh, my bug was reported
before and a fix was included in the 2.0.7 release as well as the 2.1.3,
and 2.5 releass.  I'm currently using 2.0.1 so the simplest upgrade is to
2.0.7 ... if someone else is using 2.3.4 they would either need to upgrad
to 2.5, or port their patch to the 2.3.0 branch"

if we really want to track all of this infomation better, it would
probably make sense to use the FV the way you describe (an indication
as to what release new functionality / bug-fixes have been
commited to) and have new (optional) fields indicating what FV has been
used for in the past:
  How significant is are the changes resulting from this issue?
    A - major bug fix; no api changes; should be put into an X.Y.Z
        releases ASAP
    B - minor bug fix or new functionality; only backwards compatible api
        changes, should be included in the next X.Y.0 release
    C - major functionality change; significant API changes, requires a
        new X.0 release.

Reports on A could drive the creation of point releases, Reports on B
could indicate what can be merged into release branches for minor revs,
Reports on C can tell us wether the next release from the trunk needs to
get a whole new version number to meet our compatibility policies.

...the default being "B" ... so only if you know your stuff is important
or might cause compatibility problems would you need to flag it.


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

steven_parkes
In reply to this post by steven_parkes
        not neccessarily ... if somethings in the trunk, you're saying
it should
        be included in a release eventually ... but that doesn't
neccessarily need
        ot be the 2.1 release ,it might be the 3.0 release

I can see this in theory, but do our use patterns for svn support it? My
understanding is that trunk is the proto-X.Y.0 branch. If you start
checking X.Y+1.0 or X+1.0.0 stuff in there, it's going to make creating
an X.Y.0 release difficult, right? It's possible to imagine yanking the
stuff out, but the release process just got a lot more difficult to
manage.

The svn model Lucene is using, as I understand it, is one main branch
(trunk) for development plus patch branches for cut releases (in case
patch release are ever deemed necessary). Only trunk is "actively"
maintained: it's the only thing that gets most commits. The patch
branches aren't actively maintained: things aren't pushed/committed to
them routinely. Instead, if a patch release is deemed critical, patches
are pulled/ported from trunk, facilitated by Jira and svn merge.

This makes life a lot easier. Having two branches getting "lots" of
changes is difficult to manage. I've not had to do it. And as far as I
know, Lucene has been able to function well w/o that complexity.

Will the Lucene needs ever result in a need for a more complex svn use
model? I guess a straw man example would be a 3.0 release. Say we wanted
to start working on payloads, since that's been talked about as
something big enough for people to be cautious of. How would that work
in svn? You don't want to check that into trunk today would you, if
trunk were to be planned for use of a 2.1 or 2.X?

One could start a 3.0 branch along side trunk or a 2.X branch, but
having two branches that are going to create non-patch releases is
painful, isn't it? Having to commit/test code twice? You'd presumably
want the 3.0 branch to get everything that went into any 2.X branch.

Because of the complexity, most projects I'm aware of don't want to deal
with two non-patch branches if they can at all possibly avoid it.

I'm aware of a couple of alternatives. One is to create a "payloads"
branch. It gets only the payloads work. When it's decided that work on
3.0 can commence on trunk, payloads (and anything else being withheld
for a major X.0.0 release) can get merged in.

Alternatively, you can do this work in contrib or just with patches in
svn.

The main issue is reserving trunk for things going into the next X.Y
release.

Is that the way Lucene has operated?

        i think what you are describing is really waht the intended
purpose of FV
        is ...

I did look at the Jira docs and they seem ambiguous. Can either mean
planned or completed.

One reason that one might want to reserve FV for committed code is that
it's used by the Release Notes feature. Of course, I suppose it depends
on whether one cares about that feature or if one wants it to represent
what might go in, but for me, I like the idea that it's a summary of
what's committed on the current branch. When people ask me now what's
going to be in a putative 2.1, I'd like to be able to push the Release
Notes button and say that's what's in so far. But I can't, given the way
we use FV now. Of course, that will only work if FV is used consistently
and all (significant?) work committed in svn is reflected in Jira.

        if we really want to track all of this infomation better, it
would
        probably make sense to use the FV the way you describe (an
indication
        as to what release new functionality / bug-fixes have been
        commited to) and have new (optional) fields indicating what FV
has been
        used for in the past:
          How significant is are the changes resulting from this issue?
            A - major bug fix; no api changes; should be put into an
X.Y.Z
                releases ASAP
            B - minor bug fix or new functionality; only backwards
compatible api
                changes, should be included in the next X.Y.0 release
            C - major functionality change; significant API changes,
requires a
                new X.0 release.

Hmmm ... this is starting to sound familiar. Is A the same thing as
Critical/Bug and B {Major/Minor/Trivial}/Bug?

Don't know about C. There's also Affects Version/s, so C could be New
Feature/AV/s = 3.0?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Otis Gospodnetic-2
In reply to this post by steven_parkes
Sev

----- Original Message ----
From: Steven Parkes <[hidden email]>
To: [hidden email]
Sent: Friday, October 27, 2006 4:45:16 PM
Subject: RE: releases

    not neccessarily ... if somethings in the trunk, you're saying
it should
    be included in a release eventually ... but that doesn't
neccessarily need
    ot be the 2.1 release ,it might be the 3.0 release

I can see this in theory, but do our use patterns for svn support it? My
understanding is that trunk is the proto-X.Y.0 branch. If you start
checking X.Y+1.0 or X+1.0.0 stuff in there, it's going to make creating
an X.Y.0 release difficult, right? It's possible to imagine yanking the
stuff out, but the release process just got a lot more difficult to
manage.

The svn model Lucene is using, as I understand it, is one main branch
(trunk) for development plus patch branches for cut releases (in case
patch release are ever deemed necessary). Only trunk is "actively"
maintained: it's the only thing that gets most commits. The patch
branches aren't actively maintained: things aren't pushed/committed to
them routinely. Instead, if a patch release is deemed critical, patches
are pulled/ported from trunk, facilitated by Jira and svn merge.

This makes life a lot easier. Having two branches getting "lots" of
changes is difficult to manage. I've not had to do it. And as far as I
know, Lucene has been able to function well w/o that complexity.

Will the Lucene needs ever result in a need for a more complex svn use
model? I guess a straw man example would be a 3.0 release. Say we wanted
to start working on payloads, since that's been talked about as
something big enough for people to be cautious of. How would that work
in svn? You don't want to check that into trunk today would you, if
trunk were to be planned for use of a 2.1 or 2.X?

One could start a 3.0 branch along side trunk or a 2.X branch, but
having two branches that are going to create non-patch releases is
painful, isn't it? Having to commit/test code twice? You'd presumably
want the 3.0 branch to get everything that went into any 2.X branch.

Because of the complexity, most projects I'm aware of don't want to deal
with two non-patch branches if they can at all possibly avoid it.

I'm aware of a couple of alternatives. One is to create a "payloads"
branch. It gets only the payloads work. When it's decided that work on
3.0 can commence on trunk, payloads (and anything else being withheld
for a major X.0.0 release) can get merged in.

Alternatively, you can do this work in contrib or just with patches in
svn.

The main issue is reserving trunk for things going into the next X.Y
release.

Is that the way Lucene has operated?

    i think what you are describing is really waht the intended
purpose of FV
    is ...

I did look at the Jira docs and they seem ambiguous. Can either mean
planned or completed.

One reason that one might want to reserve FV for committed code is that
it's used by the Release Notes feature. Of course, I suppose it depends
on whether one cares about that feature or if one wants it to represent
what might go in, but for me, I like the idea that it's a summary of
what's committed on the current branch. When people ask me now what's
going to be in a putative 2.1, I'd like to be able to push the Release
Notes button and say that's what's in so far. But I can't, given the way
we use FV now. Of course, that will only work if FV is used consistently
and all (significant?) work committed in svn is reflected in Jira.

    if we really want to track all of this infomation better, it
would
    probably make sense to use the FV the way you describe (an
indication
    as to what release new functionality / bug-fixes have been
    commited to) and have new (optional) fields indicating what FV
has been
    used for in the past:
      How significant is are the changes resulting from this issue?
        A - major bug fix; no api changes; should be put into an
X.Y.Z
            releases ASAP
        B - minor bug fix or new functionality; only backwards
compatible api
            changes, should be included in the next X.Y.0 release
        C - major functionality change; significant API changes,
requires a
            new X.0 release.

Hmmm ... this is starting to sound familiar. Is A the same thing as
Critical/Bug and B {Major/Minor/Trivial}/Bug?

Don't know about C. There's also Affects Version/s, so C could be New
Feature/AV/s = 3.0?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Otis Gospodnetic-2
In reply to this post by steven_parkes
Damn, funky webmail, sorry about the earlier incomplete message.

Attempt #2:

Steven,

Regarding your payloads example and 2.1 vs. 3.0, there is a simpler approach, and one that we have pretty much (unintentionally?) been using.  Larger chunks of work take longer, need more eyes to check them, to test them locally, iron out bugs, etc. and finally approve and commit them.  Therefore, while this work is in progress, it's all done via patches in JIRA, and people's local repositories.  No commits until the solid patch is available.

If the change is sufficiently large and warrants a major release, we can make the release with whatever is in the trunk, say 2.1, and then commit the big patch in the trunk that's headed for 3.0 (n.b. hypothetical version - we may have 2.2, 2.3, etc., who knows), avoiding extra branches.  Lucene is pretty mature and there are typically not that many big changes being worked on in parallel.

I think this is simpler, easier to manage, less likely to cause a mistake, requires less SVN merging knowledge, etc.  I think that's what has been practised so far, and I think it has worked pretty well.  I don't think we are looking for a change here.

Otis

----- Original Message ----
From: Steven Parkes <[hidden email]>
To: [hidden email]
Sent: Friday, October 27, 2006 4:45:16 PM
Subject: RE: releases

    not neccessarily ... if somethings in the trunk, you're saying
it should
    be included in a release eventually ... but that doesn't
neccessarily need
    ot be the 2.1 release ,it might be the 3.0 release

I can see this in theory, but do our use patterns for svn support it? My
understanding is that trunk is the proto-X.Y.0 branch. If you start
checking X.Y+1.0 or X+1.0.0 stuff in there, it's going to make creating
an X.Y.0 release difficult, right? It's possible to imagine yanking the
stuff out, but the release process just got a lot more difficult to
manage.

The svn model Lucene is using, as I understand it, is one main branch
(trunk) for development plus patch branches for cut releases (in case
patch release are ever deemed necessary). Only trunk is "actively"
maintained: it's the only thing that gets most commits. The patch
branches aren't actively maintained: things aren't pushed/committed to
them routinely. Instead, if a patch release is deemed critical, patches
are pulled/ported from trunk, facilitated by Jira and svn merge.

This makes life a lot easier. Having two branches getting "lots" of
changes is difficult to manage. I've not had to do it. And as far as I
know, Lucene has been able to function well w/o that complexity.

Will the Lucene needs ever result in a need for a more complex svn use
model? I guess a straw man example would be a 3.0 release. Say we wanted
to start working on payloads, since that's been talked about as
something big enough for people to be cautious of. How would that work
in svn? You don't want to check that into trunk today would you, if
trunk were to be planned for use of a 2.1 or 2.X?

One could start a 3.0 branch along side trunk or a 2.X branch, but
having two branches that are going to create non-patch releases is
painful, isn't it? Having to commit/test code twice? You'd presumably
want the 3.0 branch to get everything that went into any 2.X branch.

Because of the complexity, most projects I'm aware of don't want to deal
with two non-patch branches if they can at all possibly avoid it.

I'm aware of a couple of alternatives. One is to create a "payloads"
branch. It gets only the payloads work. When it's decided that work on
3.0 can commence on trunk, payloads (and anything else being withheld
for a major X.0.0 release) can get merged in.

Alternatively, you can do this work in contrib or just with patches in
svn.

The main issue is reserving trunk for things going into the next X.Y
release.

Is that the way Lucene has operated?

    i think what you are describing is really waht the intended
purpose of FV
    is ...

I did look at the Jira docs and they seem ambiguous. Can either mean
planned or completed.

One reason that one might want to reserve FV for committed code is that
it's used by the Release Notes feature. Of course, I suppose it depends
on whether one cares about that feature or if one wants it to represent
what might go in, but for me, I like the idea that it's a summary of
what's committed on the current branch. When people ask me now what's
going to be in a putative 2.1, I'd like to be able to push the Release
Notes button and say that's what's in so far. But I can't, given the way
we use FV now. Of course, that will only work if FV is used consistently
and all (significant?) work committed in svn is reflected in Jira.

    if we really want to track all of this infomation better, it
would
    probably make sense to use the FV the way you describe (an
indication
    as to what release new functionality / bug-fixes have been
    commited to) and have new (optional) fields indicating what FV
has been
    used for in the past:
      How significant is are the changes resulting from this issue?
        A - major bug fix; no api changes; should be put into an
X.Y.Z
            releases ASAP
        B - minor bug fix or new functionality; only backwards
compatible api
            changes, should be included in the next X.Y.0 release
        C - major functionality change; significant API changes,
requires a
            new X.0 release.

Hmmm ... this is starting to sound familiar. Is A the same thing as
Critical/Bug and B {Major/Minor/Trivial}/Bug?

Don't know about C. There's also Affects Version/s, so C could be New
Feature/AV/s = 3.0?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

steven_parkes
In reply to this post by steven_parkes
 
        Therefore, while this work is in progress, it's all done via
patches in JIRA,
        and people's local repositories.

This is pretty close to a separate "payloads" branch. That just provides
a shared branch, should the number of people working on that code line
require it for better communication/interactivity than patches in Jira
would provide.

Two observations:

* "typically not that many big changes being worked on in parallel":
this can become cause rather than effect. Not saying it is, just
something to look out for. If there is sufficient need and community
interest, I'm hoping we'd facilitate whatever people wanted to
contribute.

* "Lucene is pretty mature": I think people see the good side of this,
and I do too, but there can be a darker side to it. Is there a reason
why a lot of (cool) big things couldn't be going on? It could, of
course, be lack of community interest, which is fine. But is there
actually a reluctance to make changes to Lucene? I suppose the community
could be such that people thought Lucene had met its goals and didn't
need much change. I personally don't see it that way: to me, when you
have a solid piece of code, it at least potentially means you've
produced a base on which a lot of even cooler stuff can be launched.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: releases

Daniel John Debrunner-2
In reply to this post by Otis Gospodnetic-2
Otis Gospodnetic wrote:

>Regarding your payloads example and 2.1 vs. 3.0, there is a simpler approach, and one that we have
 >pretty much (unintentionally?) been using.  Larger chunks of work take
longer,
>need more eyes to  check them, to test them locally, iron out bugs, etc. and finally
 >approve and commit them.  Therefore, while this work is in progress,
it's all done
>via patches in JIRA, and people's local repositories.  No commits until the solid patch is available.

Doesn't this approach lead to less eyes on the code? An open source
trunk is usually a development line where early commits are encouraged
to enable people to run new code easily as well as looking at the code.
Having useful code only in patches puts up an additional barrier to
people looking at them.

How does this scheme work when there are multiple outstanding features,
seems very unlikely many folks will download all patches & try them
together?

Thanks,
Dan.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: releases

Chris Hostetter-3
In reply to this post by steven_parkes
: commited to) and have new (optional) fields indicating what FV
: has been
: used for in the past:
:  How significant is are the changes resulting from this issue?
:    A - major bug fix; no api changes; should be put into an
: X.Y.Z
:        releases ASAP
:    B - minor bug fix or new functionality; only backwards
: compatible api
:        changes, should be included in the next X.Y.0 release
:    C - major functionality change; significant API changes,
: requires a
:        new X.0 release.
:
: Hmmm ... this is starting to sound familiar. Is A the same thing as
: Critical/Bug and B {Major/Minor/Trivial}/Bug?
:
: Don't know about C. There's also Affects Version/s, so C could be New
: Feature/AV/s = 3.0?

The issue of bug "severity" and patch "impact" are really orthoginal ...
there could be a "Critical" bug that can only be fixed by making a
non backwards compatible change to the index file format, which would have
to be treated as "C" in my example cases.




-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]