You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Janne Jalkanen <Ja...@ecyrd.com> on 2007/12/13 11:37:30 UTC
Version numbering
Guys,
we've so far been using "major.minor.build" versioning system. This
is very good, because it allows us to unambiguously say that "this
issue was fixed in 2.5.129". Unfortunately, for error reporting this
is not very good - people get confused since we have a very "gappy"
revision history. You can't report bugs against 2.5.129, if all the
releases you have are 2.5.10 and 2.6.0. This is going to be even
more pronounced in the future, since the JIRA system is very
inflexible in this - if we put *all* our interim versions into it, I
think it will explode.
For example, Andrew just committed something and marked it 2.6.1 rc1
- how are people supposed to know that any errors are supposed to be
filed against 2.6.0, not 2.8? Not to mention that it's going to be
pretty odd if the first release is going to be 2.6.45 instead of
2.6.0...
Anybody have any suggestions? I would very much like to retain the
ability to clearly say which "build" has what (as it, among other
things, encourages us to do small, stable commits, which are good for
overall project stability), but error management is going to be a
bigger hassle in the future.
Of course, if there are JIRA wizards among us, they could perhaps
suggest an alternative method of release management? ;-)
Also, please consider branching issues. Currently we are branching
stables off the trunk, but usually only at release, or afterwards.
/Janne
Re: Version numbering
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Janne,
On Dec 13, 2007, at 2:37 AM, Janne Jalkanen wrote:
> Guys,
>
> we've so far been using "major.minor.build" versioning system.
> This is very good, because it allows us to unambiguously say that
> "this issue was fixed in 2.5.129". Unfortunately, for error
> reporting this is not very good - people get confused since we have
> a very "gappy" revision history. You can't report bugs against
> 2.5.129, if all the releases you have are 2.5.10 and 2.6.0.
IMO, you should identify bugs against released code, using the
earliest release that exposes the bug. Often, the reporter is only
interested in one release but the bug is actually in earlier and
later releases. So the reporter might say the bug is in 2.5.1 but it
was actually introduced in 2.4.6. The person who fixes the bug should
try to figure out which releases the bug applies to and update the
jira to suit.
Bugs that are in the trunk and have never been released are more
challenging. I'd say to report these bugs, identify them by the
release version in the trunk and the build (svn "r") number. JIRA
doesn't have the ability to be this precise, but does allow you to
mark the bug as being in an unreleased version and then the text of
the JIRA spells out the build number. For example, if the result if
building the trunk is 2.6.1-SNAPSHOT, the bug can be reported against
"2.6.1-SNAPSHOT r557089".
When a bug is fixed, the svn commit message should contain the JIRA
number. Then the JIRA itself will be automatically updated to contain
the svn revision number. The "fixed in" can be simply 2.6.1.
> This is going to be even more pronounced in the future, since the
> JIRA system is very inflexible in this - if we put *all* our
> interim versions into it, I think it will explode.
It is up to the team to decide how to use JIRA. If you don't want to
put all 388 versions into it, you have to choose whether to use JIRA
for just the first two digits, or to be more selective about what you
call releases.
In Apache, a release is a very specific thing. It's voted by the team
and is signed and archived and mirrored. So having 388 versions would
keep someone very busy for a very long time. Typically, in Apache
projects, releases are made at most every couple of months.
>
> For example, Andrew just committed something and marked it 2.6.1
> rc1 - how are people supposed to know that any errors are supposed
> to be filed against 2.6.0, not 2.8? Not to mention that it's going
> to be pretty odd if the first release is going to be 2.6.45 instead
> of 2.6.0...
When moving the repo and the package naming to Apache it would be
good to decide how to do this. Other projects have a release naming
scheme that is simply three digits, and uses the terminology -
SNAPSHOT to mark interim releases. So while you're working on 3.0,
the builds are marked 3.0-SNAPSHOT. This avoids the 3.0.45 problem.
>
> Anybody have any suggestions? I would very much like to retain the
> ability to clearly say which "build" has what (as it, among other
> things, encourages us to do small, stable commits, which are good
> for overall project stability), but error management is going to be
> a bigger hassle in the future.
>
> Of course, if there are JIRA wizards among us, they could perhaps
> suggest an alternative method of release management? ;-)
Right now, there are only two releases in JIRA (2.6 and 3.0), so
we've avoided the issue for now.
>
> Also, please consider branching issues. Currently we are branching
> stables off the trunk, but usually only at release, or afterwards.
I'd suggest looking at release policy for other projects for ideas.
For example, please see http://openjpa.apache.org/building-
openjpa.html and http://openjpa.apache.org/openjpareleasepolicy.html
and http://openjpa.apache.org/releasing-openjpa.html
Craig
>
> /Janne
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Version numbering
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
First proposal is at http://www.jspwiki.org/wiki/VersioningProposal
Didn't have much time; have to go so I'll get back to that later this
evening.
/Janne
Re: Version numbering
Posted by Craig L Russell <Cr...@Sun.COM>.
Hey,
On Dec 13, 2007, at 12:24 PM, Janne Jalkanen wrote:
>
> With SVN, the entire repository has a single "build number". It
> should be possible to embed this in Release.class somehow.
Yes, OpenJPA does this.
> Of course, it will increase whenever someone even breathes at the
> repository, so it's not really indicative of any changes.
I don't think this is really an issue, even though from JSPWiki's
perspective, there's nothing different between svn revisions r668409
and r668578. You can get the same JSPWiki code base from svn by
asking for any of these revisions to be checked out.
> I like a manually updated "build number", since it's indicative of
> when something actually really changes.
If you can embed the build number in the code this can also be useful.
>
> And actually, now I think about it, I think SVN's version number is
> common to the entire repository, so it will increase even if
> someone updates another project... I don't think that's a very
> good indicator.
>
> Of course, our development branch does not really care. We could
> still be running 2.7.1, 2.7.2, etc, and say it's "2.7.x" in the bug
> reporting tool.
>
> Apache will require us to put the word "incubating" in it, if we
> release before moving out of the incubation process, so we'll have
> somewhat interesting release names... 2.7.234-incubating build
> 3943 ;-).
>
> Also, we have to think about branches. Should a build number be
> unique across all branches, or should it be something which is used
> within one branch only? (i.e. is it possible to have 2.6.1-14,
> 2.7.1-14, and 2.7.4-14?) If it's unique across all branches, it'll
> end up being gappy, and then it must be automatically allocated, or
> developers will need to keep manually track of the latest build
> number.
>
> Nevertheless, I'd like to propose that with 2.6, we *don't* up the
> release number anymore - 2.6.0 is the first released version, 2.6.1
> is the next one release and so on. Let's keep bumping the "rcxxx"
> number.
Yeah, bumping the rc number is good, if I understand you correctly.
You might try to release 2.6.0 by cutting a 2.6.0-rc1 and if there
are problems with that, 2.6.0-rc2... and finally release a 2.6.0-
rc34. ;-)
A related issue is the naming of the directories. You've already
noted the "incubating" requirement, but the release artifacts should
not contain -rcxxx. The builds that you vote on will contain the
rcxxx in the directory, but internally it's not rcxxx but 2.6.0 build
yyy. For example, release candidates might be posted at http://
people.apache.org/~jalkanen/2.6.0-incubating-rc2. The only place that
rc2 appears is in this directory. The release candidate bits contain
the final numbering scheme, e.g. http://people.apache.org/~jalkanen/
2.6.0-incubating-rc2/jspwiki-2.6.0-incubating-src.zip.
Craig
>
> /Janne
>
> On 13 Dec 2007, at 16:36, Andrew Jaquith wrote:
>
>> Olaf has the right idea. Keep the version numbers and build
>> numbers separate.
>>
>> A good example is Parallels. Every downloadable version offered to
>> the public has a major and minor version number: 3.0, 3.0-rc1,
>> etc. There's also a build number: 4128, 5150, 5370.
>>
>> From the standpoint of release control, the rules would proplably
>> work like this:
>> - every time a committer checks in a batch of stuff (code or
>> otherwise), they must increment the build number
>> - the release number is only changed upon stable releases, or at
>> the pleasure of a benevolent dictator (Janne)
>>
>> All we really need to do, then, is add a build number field to
>> Release.java and make sure we can get people to report it in JIRA.
>>
>> Andrew
>>
>> On Dec 13, 2007, at 6:53, Olaf Kock <ok...@abstrakt.de> wrote:
>>
>>> Janne Jalkanen schrieb:
>>> [...]
>>>> Anybody have any suggestions? I would very much like to retain the
>>>> ability to clearly say which "build" has what (as it, among other
>>>> things, encourages us to do small, stable commits, which are
>>>> good for
>>>> overall project stability), but error management is going to be
>>>> a bigger
>>>> hassle in the future.
>>>>
>>>> Of course, if there are JIRA wizards among us, they could perhaps
>>>> suggest an alternative method of release management? ;-)
>>>
>>> I don't know if I count as JIRA wizard, but I'm quite happy handling
>>> version numbers and builds as distinct information. Therefor a
>>> version
>>> is whatever is voted stable and deserves its own (manual) numbering
>>> scheme. The build number is issued by our continouus integration
>>> server
>>> which boils down to every single commit resulting in a new build
>>> number.
>>>
>>> Issues are usually reported against version numbers, but may be
>>> fixed
>>> with a remark like "fixed in build 1234" (but flagged fixed for
>>> the next
>>> to be released version).
>>>
>>> If somebody insists, the "fix build" may be saved as a custom
>>> field in
>>> Jira, we are usually just entering it in the fix comments.
>>> (Nobody has
>>> ever wanted to have a report of fixed issues per build number)
>>>
>>> This gives best of both worlds: Nobody gets confused about why
>>> 1.0.42 is
>>> a must-have while 1.0.49 is a risky build. For customers the CI-
>>> server
>>> flags almost all builds as "internal build" (and the build number is
>>> displayed in the application, so it is known to be unsupported)
>>> while
>>> release versions get their labelling changed.
>>>
>>> Our typical label numbering scheme is something like this:
>>>
>>> 1.0.0.build-42
>>> 1.0.1.internal-build-49
>>> 1.0.1.build-54
>>>
>>> (trailing numbers are incremented by the build server)
>>>
>>> Hope this helps,
>>> Olaf
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Version numbering
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
With SVN, the entire repository has a single "build number". It
should be possible to embed this in Release.class somehow. Of
course, it will increase whenever someone even breathes at the
repository, so it's not really indicative of any changes. I like a
manually updated "build number", since it's indicative of when
something actually really changes.
And actually, now I think about it, I think SVN's version number is
common to the entire repository, so it will increase even if someone
updates another project... I don't think that's a very good indicator.
Of course, our development branch does not really care. We could
still be running 2.7.1, 2.7.2, etc, and say it's "2.7.x" in the bug
reporting tool.
Apache will require us to put the word "incubating" in it, if we
release before moving out of the incubation process, so we'll have
somewhat interesting release names... 2.7.234-incubating build 3943 ;-).
Also, we have to think about branches. Should a build number be
unique across all branches, or should it be something which is used
within one branch only? (i.e. is it possible to have 2.6.1-14,
2.7.1-14, and 2.7.4-14?) If it's unique across all branches, it'll
end up being gappy, and then it must be automatically allocated, or
developers will need to keep manually track of the latest build number.
Nevertheless, I'd like to propose that with 2.6, we *don't* up the
release number anymore - 2.6.0 is the first released version, 2.6.1
is the next one release and so on. Let's keep bumping the "rcxxx"
number.
/Janne
On 13 Dec 2007, at 16:36, Andrew Jaquith wrote:
> Olaf has the right idea. Keep the version numbers and build
> numbers separate.
>
> A good example is Parallels. Every downloadable version offered to
> the public has a major and minor version number: 3.0, 3.0-rc1, etc.
> There's also a build number: 4128, 5150, 5370.
>
> From the standpoint of release control, the rules would proplably
> work like this:
> - every time a committer checks in a batch of stuff (code or
> otherwise), they must increment the build number
> - the release number is only changed upon stable releases, or at
> the pleasure of a benevolent dictator (Janne)
>
> All we really need to do, then, is add a build number field to
> Release.java and make sure we can get people to report it in JIRA.
>
> Andrew
>
> On Dec 13, 2007, at 6:53, Olaf Kock <ok...@abstrakt.de> wrote:
>
>> Janne Jalkanen schrieb:
>> [...]
>>> Anybody have any suggestions? I would very much like to retain the
>>> ability to clearly say which "build" has what (as it, among other
>>> things, encourages us to do small, stable commits, which are good
>>> for
>>> overall project stability), but error management is going to be a
>>> bigger
>>> hassle in the future.
>>>
>>> Of course, if there are JIRA wizards among us, they could perhaps
>>> suggest an alternative method of release management? ;-)
>>
>> I don't know if I count as JIRA wizard, but I'm quite happy handling
>> version numbers and builds as distinct information. Therefor a
>> version
>> is whatever is voted stable and deserves its own (manual) numbering
>> scheme. The build number is issued by our continouus integration
>> server
>> which boils down to every single commit resulting in a new build
>> number.
>>
>> Issues are usually reported against version numbers, but may be fixed
>> with a remark like "fixed in build 1234" (but flagged fixed for
>> the next
>> to be released version).
>>
>> If somebody insists, the "fix build" may be saved as a custom
>> field in
>> Jira, we are usually just entering it in the fix comments. (Nobody
>> has
>> ever wanted to have a report of fixed issues per build number)
>>
>> This gives best of both worlds: Nobody gets confused about why
>> 1.0.42 is
>> a must-have while 1.0.49 is a risky build. For customers the CI-
>> server
>> flags almost all builds as "internal build" (and the build number is
>> displayed in the application, so it is known to be unsupported) while
>> release versions get their labelling changed.
>>
>> Our typical label numbering scheme is something like this:
>>
>> 1.0.0.build-42
>> 1.0.1.internal-build-49
>> 1.0.1.build-54
>>
>> (trailing numbers are incremented by the build server)
>>
>> Hope this helps,
>> Olaf
Re: Version numbering
Posted by Andrew Jaquith <an...@mac.com>.
Olaf has the right idea. Keep the version numbers and build numbers
separate.
A good example is Parallels. Every downloadable version offered to the
public has a major and minor version number: 3.0, 3.0-rc1, etc.
There's also a build number: 4128, 5150, 5370.
From the standpoint of release control, the rules would proplably
work like this:
- every time a committer checks in a batch of stuff (code or
otherwise), they must increment the build number
- the release number is only changed upon stable releases, or at the
pleasure of a benevolent dictator (Janne)
All we really need to do, then, is add a build number field to
Release.java and make sure we can get people to report it in JIRA.
Andrew
On Dec 13, 2007, at 6:53, Olaf Kock <ok...@abstrakt.de> wrote:
> Janne Jalkanen schrieb:
> [...]
>> Anybody have any suggestions? I would very much like to retain the
>> ability to clearly say which "build" has what (as it, among other
>> things, encourages us to do small, stable commits, which are good for
>> overall project stability), but error management is going to be a
>> bigger
>> hassle in the future.
>>
>> Of course, if there are JIRA wizards among us, they could perhaps
>> suggest an alternative method of release management? ;-)
>
> I don't know if I count as JIRA wizard, but I'm quite happy handling
> version numbers and builds as distinct information. Therefor a version
> is whatever is voted stable and deserves its own (manual) numbering
> scheme. The build number is issued by our continouus integration
> server
> which boils down to every single commit resulting in a new build
> number.
>
> Issues are usually reported against version numbers, but may be fixed
> with a remark like "fixed in build 1234" (but flagged fixed for the
> next
> to be released version).
>
> If somebody insists, the "fix build" may be saved as a custom field in
> Jira, we are usually just entering it in the fix comments. (Nobody has
> ever wanted to have a report of fixed issues per build number)
>
> This gives best of both worlds: Nobody gets confused about why
> 1.0.42 is
> a must-have while 1.0.49 is a risky build. For customers the CI-server
> flags almost all builds as "internal build" (and the build number is
> displayed in the application, so it is known to be unsupported) while
> release versions get their labelling changed.
>
> Our typical label numbering scheme is something like this:
>
> 1.0.0.build-42
> 1.0.1.internal-build-49
> 1.0.1.build-54
>
> (trailing numbers are incremented by the build server)
>
> Hope this helps,
> Olaf
Re: Version numbering
Posted by Olaf Kock <ok...@abstrakt.de>.
Janne Jalkanen schrieb:
[...]
> Anybody have any suggestions? I would very much like to retain the
> ability to clearly say which "build" has what (as it, among other
> things, encourages us to do small, stable commits, which are good for
> overall project stability), but error management is going to be a bigger
> hassle in the future.
>
> Of course, if there are JIRA wizards among us, they could perhaps
> suggest an alternative method of release management? ;-)
I don't know if I count as JIRA wizard, but I'm quite happy handling
version numbers and builds as distinct information. Therefor a version
is whatever is voted stable and deserves its own (manual) numbering
scheme. The build number is issued by our continouus integration server
which boils down to every single commit resulting in a new build number.
Issues are usually reported against version numbers, but may be fixed
with a remark like "fixed in build 1234" (but flagged fixed for the next
to be released version).
If somebody insists, the "fix build" may be saved as a custom field in
Jira, we are usually just entering it in the fix comments. (Nobody has
ever wanted to have a report of fixed issues per build number)
This gives best of both worlds: Nobody gets confused about why 1.0.42 is
a must-have while 1.0.49 is a risky build. For customers the CI-server
flags almost all builds as "internal build" (and the build number is
displayed in the application, so it is known to be unsupported) while
release versions get their labelling changed.
Our typical label numbering scheme is something like this:
1.0.0.build-42
1.0.1.internal-build-49
1.0.1.build-54
(trailing numbers are incremented by the build server)
Hope this helps,
Olaf