You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by rh...@apache.org on 2009/02/09 15:09:56 UTC
svn commit: r742512 -
/db/derby/code/branches/10.4/tools/ant/properties/release.properties
Author: rhillegas
Date: Mon Feb 9 14:09:56 2009
New Revision: 742512
URL: http://svn.apache.org/viewvc?rev=742512&view=rev
Log:
Bump the fourth digit of the 10.4 release id.
Modified:
db/derby/code/branches/10.4/tools/ant/properties/release.properties
Modified: db/derby/code/branches/10.4/tools/ant/properties/release.properties
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.4/tools/ant/properties/release.properties?rev=742512&r1=742511&r2=742512&view=diff
==============================================================================
--- db/derby/code/branches/10.4/tools/ant/properties/release.properties (original)
+++ db/derby/code/branches/10.4/tools/ant/properties/release.properties Mon Feb 9 14:09:56 2009
@@ -15,10 +15,10 @@
#Wed Apr 16 19:11:46 CEST 2008
major=10
-maint=2000001
+maint=2000002
drdamaint=0
minor=4
eversion=10.4
-copyright.comment=Copyright 1997, 2008 The Apache Software Foundation or its licensors, as applicable.
+copyright.comment=Copyright 1997, 2009 The Apache Software Foundation or its licensors, as applicable.
beta=false
vendor=The Apache Software Foundation
Re: Bumping the fourth digit
Posted by Myrna van Lunteren <m....@gmail.com>.
On Tue, Feb 10, 2009 at 11:08 AM, Kristian Waagan
<Kr...@sun.com> wrote:
> Kathey Marsden wrote:
>>
>> Rick Hillegas wrote:
>>>
>>> Where should be track that association of external releases with
>>> subversion commit-stamps? On the wiki? In a special JIRA entry?
>>>
>> I think when you create a version, you can put in a comment which is
>> displayed here:
>>
>> https://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:versions-panel
>>
>> Can these comments be edited? If so, we could update them with the final
>> subversion commit for the version.
>
> Yes, the comments can be edited by those listed as administrators for the
> Derby Jira project. This list currently consists of the following people:
> Andrew McIntyre, Jean T. Anderson, Kristian Waagan, Rick Hillegas, Rodent of
> Unusual Size. The role of an administrator mostly consists of merging /
> managing versions, assigning new contributers to the developer role,
> assigning developers to the committer role, and assigning people to the PMC
> role. Except for the ability to assign issues to oneself when being in the
> list of contributers, I'm not sure if the other roles are actually paid
> attention to or used for anything special.
> Did I forget something?
>
> Also, we share a Jira instance with many other ASF projects, so the
> possibility to make custom changes may have been somewhat restricted. In
> general, I think Jira is working nicely. The most annoying thing coming up
> in my mind, is that you can't set the patch available flag when you upload a
> new file. It has to be done in a separate step. This is no big deal though.
>
> I also like to have a release date set for the various releases, but it is
> not quite clear to me which date is considered as the release date;
> o the date of the latest Subversion commit for the release?
> o the date the release artifacts are published and made publicly available?
> o the date when the release was built?
> o the date the community vote passes?
> o a date determined by the release manager?
> o another date?
>
>
> --
> Kristian
>
>>
>> Kathey
>>
>>
>>
>
>
I agree that this spot in JIRA seems the perfect place to log info re
the 4th digit versions. I think once we know, maybe we could even add
the first revision as of which the new 4th digit version is valid.
Re date for official builds - from a support point of view I'd say the
built date - this is something we can have a user check on in addition
to the build number we get from sysinfo. (jar -tvf on e.g. derby.jar)
to see if they've got the officially posted build, or a build from
somewhere else...
Or maybe we can have a little more extensive info listed here for the
official builds - for instance: last commit revision: 12345 on
mm-dd-yyyy; build date: mm-dd-yyyy; vote passed: mm-dd-yyyy. (Some of
that info won't be available at the time the version is entered in
JIRA, of course).
Going back to the fourth digit issue - how do we proceed, can we just
accept this as our policy (and then Rick can redo his commit provided
some bookkeeping of 10.4.2.1 fixes is done) or do we need to vote on
this process?
Myrna
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kristian Waagan wrote:
> Kathey Marsden wrote:
>> Rick Hillegas wrote:
>>> Where should be track that association of external releases with
>>> subversion commit-stamps? On the wiki? In a special JIRA entry?
>>>
>> I think when you create a version, you can put in a comment which is
>> displayed here:
>> https://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:versions-panel
>>
>>
>> Can these comments be edited? If so, we could update them with the
>> final subversion commit for the version.
>
> Yes, the comments can be edited by those listed as administrators for
> the Derby Jira project. This list currently consists of the following
> people: Andrew McIntyre, Jean T. Anderson, Kristian Waagan, Rick
> Hillegas, Rodent of Unusual Size. The role of an administrator mostly
> consists of merging / managing versions, assigning new contributers to
> the developer role, assigning developers to the committer role, and
> assigning people to the PMC role. Except for the ability to assign
> issues to oneself when being in the list of contributers, I'm not sure
> if the other roles are actually paid attention to or used for anything
> special.
> Did I forget something?
>
> Also, we share a Jira instance with many other ASF projects, so the
> possibility to make custom changes may have been somewhat restricted.
> In general, I think Jira is working nicely. The most annoying thing
> coming up in my mind, is that you can't set the patch available flag
> when you upload a new file. It has to be done in a separate step. This
> is no big deal though.
>
> I also like to have a release date set for the various releases, but
> it is not quite clear to me which date is considered as the release date;
> o the date of the latest Subversion commit for the release?
> o the date the release artifacts are published and made publicly
> available?
> o the date when the release was built?
> o the date the community vote passes?
> o a date determined by the release manager?
> o another date?
For official releases, I think it will look goofy if the release date
here doesn't agree with the release date on the download page. I don't
think the download page has had a consistent policy over the last four
years. For the past couple releases, the date on the download page is
the day that the vote passed. For 10.4.1.3, it is the day after the vote
passed. Since an Apache distribution isn't considered "released" until
after the vote ends, that's the earliest date I would recommend for this
field. Going forward, I'd be happy to standardize on the date that the
vote passed.
For unofficial releases, I guess it's up to whoever produced the
distribution to declare when they think that the distribution was released.
>
>
Re: Bumping the fourth digit
Posted by Kristian Waagan <Kr...@Sun.COM>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
>> Where should be track that association of external releases with
>> subversion commit-stamps? On the wiki? In a special JIRA entry?
>>
> I think when you create a version, you can put in a comment which is
> displayed here:
> https://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:versions-panel
>
>
> Can these comments be edited? If so, we could update them with the
> final subversion commit for the version.
Yes, the comments can be edited by those listed as administrators for
the Derby Jira project. This list currently consists of the following
people: Andrew McIntyre, Jean T. Anderson, Kristian Waagan, Rick
Hillegas, Rodent of Unusual Size. The role of an administrator mostly
consists of merging / managing versions, assigning new contributers to
the developer role, assigning developers to the committer role, and
assigning people to the PMC role. Except for the ability to assign
issues to oneself when being in the list of contributers, I'm not sure
if the other roles are actually paid attention to or used for anything
special.
Did I forget something?
Also, we share a Jira instance with many other ASF projects, so the
possibility to make custom changes may have been somewhat restricted. In
general, I think Jira is working nicely. The most annoying thing coming
up in my mind, is that you can't set the patch available flag when you
upload a new file. It has to be done in a separate step. This is no big
deal though.
I also like to have a release date set for the various releases, but it
is not quite clear to me which date is considered as the release date;
o the date of the latest Subversion commit for the release?
o the date the release artifacts are published and made publicly available?
o the date when the release was built?
o the date the community vote passes?
o a date determined by the release manager?
o another date?
--
Kristian
>
> Kathey
>
>
>
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
>>
>> As a test of this, I have updated the description of 10.4.2.1. You
>> can see this by clicking on the link you forwarded. Does this format
>> look reasonable to you?
>>
> I think we cannot include an url to the Sun build in Jira. According to:
> http://www.apache.org/dev/release.html
>
> "Do not include any links on the project website that might encourage
> non-developers to download and use nightly builds, snapshots, release
> candidates, or any other similar package.
> ...
> Under no circumstances are unapproved builds a substitute for
> releases. If this policy seems inconvenient, then release more often.
> Proper release management is a key aspect of Apache software development.
>
> Just the subversion commit number should be sufficient in the Jira
> version comment I think.
Makes sense to me.
Cheers,
-Rick
>
>
> Kathey
>
Re: Bumping the fourth digit
Posted by Myrna van Lunteren <m....@gmail.com>.
On Fri, Feb 13, 2009 at 11:24 AM, Dag H. Wanvik <Da...@sun.com> wrote:
>
> I think we should try to keep this simple; bump the last digit when
> somebody requests it on the branch to make a point referenceable (it
> could be an external release, or a release candidate, or whatever). I
> sort of like Mike's suggestion of doing it for every commit on the
> branch, but I understand that could upset some expectations and may be
> too radical.
>
> Dag
>
I like simple.
Does anyone know of a good place to document this - i.e. that you can
request for a version number bump, to checkpoint a bug fix level - on
the web/wiki?
Myrna
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Andrew McIntyre wrote:
> On Wed, Feb 18, 2009 at 5:53 AM, Rick Hillegas <Ri...@sun.com> wrote:
>
>> Hi Andrew,
>>
>> Can you help me understand why we need to add 2 new versions to JIRA and not
>> just 1? One of the versions means "the next official release on this
>> branch". I understand what to do with that release id: I put it in the
>> "fixed in" field.
>>
>> But I don't understand what to do with the other version. Does the other
>> version mean "the next (unofficial) patch distribution on this branch"? Is
>> this release id meant to go in the "affects version" field? There has been
>> some discomfort expressed on this email thread about using the JIRA fields
>> to hold the release ids of distributions which were created outside the
>> community.
>>
>> How do you think the 2 JIRA release ids should they be used in JIRA reports?
>>
>
> We've gone over this before. See this thread and specifically my reply here:
>
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200708.mbox/%3C54ac72d70708141631y6f5635d4s3e0b6b08a13ab762@mail.gmail.com%3E
>
> I think what is important to maintain is that the 'fixed in' version
> in JIRA matches the sysinfo version, so that one can match fixes in
> JIRA to what is in a specific build by examining the range of
> subversion commits bounded by the version number and build number of
> the build artifact.
>
> I think the 'next' version is useful for release planning, but if it's
> not actually being used for that in any meaningful way, then I can see
> why they might be viewed as clutter. Certainly the '11.0.0.0' version
> is a 'next' version that is meaningful, but perhaps the branch 'next'
> versions are not.
>
> I think it's ok to bump the fourth digit of the version for any reason
> you like, as long as you're not promoting the idea that builds created
> around those version bumps qualify as official Apache releases.
>
> andrew
>
Thanks for that pointer, Andrew. That helps me understand your thinking
better. That thread aired a lot of useful opinions and proposed several
productive models. It seems to me that the thread tapered off without
reaching consensus. That could help explain why so many models are still
in play here.
I am prepared to declare an end to this original email thread. It seems
to me that
1) There is broad consensus that it's ok to bump the fourth digit of the
release id often and without initiating a community discussion.
2) We may need to launch a new discussion to settle the meaning of our
JIRA release ids and the meaning of the "affects version" and "fixed in
version" fields.
Thanks,
-Rick
Re: Bumping the fourth digit
Posted by Andrew McIntyre <mc...@gmail.com>.
On Wed, Feb 18, 2009 at 5:53 AM, Rick Hillegas <Ri...@sun.com> wrote:
>
> Hi Andrew,
>
> Can you help me understand why we need to add 2 new versions to JIRA and not
> just 1? One of the versions means "the next official release on this
> branch". I understand what to do with that release id: I put it in the
> "fixed in" field.
>
> But I don't understand what to do with the other version. Does the other
> version mean "the next (unofficial) patch distribution on this branch"? Is
> this release id meant to go in the "affects version" field? There has been
> some discomfort expressed on this email thread about using the JIRA fields
> to hold the release ids of distributions which were created outside the
> community.
>
> How do you think the 2 JIRA release ids should they be used in JIRA reports?
We've gone over this before. See this thread and specifically my reply here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200708.mbox/%3C54ac72d70708141631y6f5635d4s3e0b6b08a13ab762@mail.gmail.com%3E
I think what is important to maintain is that the 'fixed in' version
in JIRA matches the sysinfo version, so that one can match fixes in
JIRA to what is in a specific build by examining the range of
subversion commits bounded by the version number and build number of
the build artifact.
I think the 'next' version is useful for release planning, but if it's
not actually being used for that in any meaningful way, then I can see
why they might be viewed as clutter. Certainly the '11.0.0.0' version
is a 'next' version that is meaningful, but perhaps the branch 'next'
versions are not.
I think it's ok to bump the fourth digit of the version for any reason
you like, as long as you're not promoting the idea that builds created
around those version bumps qualify as official Apache releases.
andrew
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Knut Anders Hatlen wrote:
>
> Hi Rick,
>
> My understanding is actually the opposite: 10.3.4.0 refers to the next
> official release and should not be used for the "fixed in" field for the
> fixes that we have committed. (At one point we may have used it to say
> "it is my intention to fix this bug for that release", but that's not so
> common anymore.)
>
>
Thanks, Knut. Are you following the advice of some page on our website
or some email thread--and if so, could you point me at those
discussions? I don't find much guidance at
http://db.apache.org/derby/DerbyBugGuidelines.html or at the document it
points at: "Filing Apache Derby Issues in Jira".
Thanks,
-Rick
Re: Bumping the fourth digit
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Rick Hillegas <Ri...@Sun.COM> writes:
> Hi Andrew,
>
> Can you help me understand why we need to add 2 new versions to JIRA
> and not just 1? One of the versions means "the next official release
> on this branch". I understand what to do with that release id: I put
> it in the "fixed in" field.
>
> But I don't understand what to do with the other version. Does the
> other version mean "the next (unofficial) patch distribution on this
> branch"? Is this release id meant to go in the "affects version"
> field? There has been some discomfort expressed on this email thread
> about using the JIRA fields to hold the release ids of distributions
> which were created outside the community.
Hi Rick,
My understanding is actually the opposite: 10.3.4.0 refers to the next
official release and should not be used for the "fixed in" field for the
fixes that we have committed. (At one point we may have used it to say
"it is my intention to fix this bug for that release", but that's not so
common anymore.)
10.3.3.1 refers to the current state of the 10.3 branch and should be
used in the "fixed in" field for fixes merged to that branch. It should
also be used in "affects version" if it is a bug introduced on the 10.3
branch after the release of 10.3.3.0 (aka regression).
I think it would be less confusing if we didn't add version numbers to
JIRA until we have a branch where sysinfo reports that version
number. Apart from adding confusion as to which number to use in reports
and what the numbers actually mean, having many unreleased version
numbers also causes JIRA usability issues like DERBY-4058.
--
Knut Anders
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Andrew McIntyre wrote:
> On Tue, Feb 17, 2009 at 1:00 PM, Rick Hillegas <Ri...@sun.com> wrote:
>
>> I prefer the first approach. I would like to summarize its features:
>>
>> a) Any committer can bump the 4th digit of the release id without initiating
>> a community discussion. This lets people create new patch distributions with
>> unique release ids that distinguish them from community releases.
>>
>
> +1 - I also think that any committer should feel free to bump the
> fourth version whenever they feel like it.
>
> On a side note, there's nothing to say you can't still build snapshots
> if you want to share with the dev list what you built. You just
> shouldn't publicize it elsewhere.
>
>
>> b) When the release manager publishes a new official release, the 4th digit
>> of the release id is bumped on the branch. The meaning of the branch id is
>> "the next (unofficial) patch distribution produced on this branch." At the
>> same time, a new release id is added to JIRA. The meaning of this new JIRA
>> release id is "the next official release on this branch". This release id is
>> even further advanced: its 3rd digit is bumped.
>>
>
> +1. I think the lack of a "next" JIRA ID for 10.3 and 10.4 is simply
> oversight, I know I forgot to add 10.3.4.0 after releasing 10.3.3.0.
> I've gone ahead and added them. I will update item 13 in the release
> instructions to be clear that two new versions need to be added at the
> end of the process.
>
> andrew
>
Hi Andrew,
Can you help me understand why we need to add 2 new versions to JIRA and
not just 1? One of the versions means "the next official release on this
branch". I understand what to do with that release id: I put it in the
"fixed in" field.
But I don't understand what to do with the other version. Does the other
version mean "the next (unofficial) patch distribution on this branch"?
Is this release id meant to go in the "affects version" field? There has
been some discomfort expressed on this email thread about using the JIRA
fields to hold the release ids of distributions which were created
outside the community.
How do you think the 2 JIRA release ids should they be used in JIRA reports?
Thanks,
-Rick
Re: Bumping the fourth digit
Posted by Andrew McIntyre <mc...@gmail.com>.
On Tue, Feb 17, 2009 at 1:00 PM, Rick Hillegas <Ri...@sun.com> wrote:
>
> I prefer the first approach. I would like to summarize its features:
>
> a) Any committer can bump the 4th digit of the release id without initiating
> a community discussion. This lets people create new patch distributions with
> unique release ids that distinguish them from community releases.
+1 - I also think that any committer should feel free to bump the
fourth version whenever they feel like it.
On a side note, there's nothing to say you can't still build snapshots
if you want to share with the dev list what you built. You just
shouldn't publicize it elsewhere.
> b) When the release manager publishes a new official release, the 4th digit
> of the release id is bumped on the branch. The meaning of the branch id is
> "the next (unofficial) patch distribution produced on this branch." At the
> same time, a new release id is added to JIRA. The meaning of this new JIRA
> release id is "the next official release on this branch". This release id is
> even further advanced: its 3rd digit is bumped.
+1. I think the lack of a "next" JIRA ID for 10.3 and 10.4 is simply
oversight, I know I forgot to add 10.3.4.0 after releasing 10.3.3.0.
I've gone ahead and added them. I will update item 13 in the release
instructions to be clear that two new versions need to be added at the
end of the process.
andrew
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks to everyone for the discussion so far. I have looked more closely
at what is actually happening in JIRA and the branches. It seems to me
that the community has been following two different approaches for
managing release ids:
1) The approach followed by 10.1 and 10.2.
2) The approach followed by 10.3 and 10.4.
I prefer the first approach. I would like to summarize its features:
a) Any committer can bump the 4th digit of the release id without
initiating a community discussion. This lets people create new patch
distributions with unique release ids that distinguish them from
community releases.
b) When the release manager publishes a new official release, the 4th
digit of the release id is bumped on the branch. The meaning of the
branch id is "the next (unofficial) patch distribution produced on this
branch." At the same time, a new release id is added to JIRA. The
meaning of this new JIRA release id is "the next official release on
this branch". This release id is even further advanced: its 3rd digit is
bumped.
Here is what I am seeing today:
Branch Latest Official Release Current Release ID on
Branch Highest JIRA (next official) Release ID
10.1 10.1.3.1 10.1.3.3
10.1.4.0
10.2 10.2.2.0 10.2.2.1
10.2.3.0
10.3 10.3.3.0
10.3.3.1 10.3.3.1
10.4 10.4.2.0
10.4.2.1 10.4.2.1
I propose that we adopt (1) as our policy going forward. If the
community agrees, then I propose to bring JIRA's "next" ids for 10.3 and
10.4 into agreement with this policy:
i) rename the next official 10.3 release to be 10.3.4.0
ii) rename the next official 10.4 release to be 10.4.3.0
Here are the practical consequences of this policy for Myrna when she
publishes a 10.5.1.2 release:
iii) she will bump the release id on the 10.5 branch to be 10.5.1.3
iv) she will add a new release id to JIRA: 10.5.2.0
Does this sound OK?
Thanks,
-Rick
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Mike Matrigali wrote:
> I don't have a problem with allowing 4th digit bumps to any branch
> by any committer. If someone wanted to bump this with every change
> I also would not have a problem. As Kathey mentioned this would
> force a query recompile for every fix which might be safer, rather
> than force someone to remember it if the fix required the recompile.
> Even if there is not an official apache release
> it can help the discussion between developers working on their own
> builds off the branch to better exactly describe the code they are
> working. The svn build number included helps with this but some
> tools and applications just deal with the 4 part version number more
> naturally.
>
> Should we just change the build process to make the 4th digit
> the build number, ie. the svn number of the last change included
> in the build? This would give an exact release id for every
> change and not require manual intervention. Does this break something?
> I know some process requires one of these numbers to be 0 to force
> a bets.
If the 3rd number is 0, then the distribution is marked as "alpha". The
"beta-ness" of a distribution is determined by a special beta flag in
tools/ant/properties/release.properties. I don't think the build changes
are very complicated for making our release ids look like 10.3.3.706492
(to use Kathey's example). There would be some chicken-and-egg problems
associated with generating the release notes since they are checked into
the codeline and are compiled from issues that are marked for inclusion
in the release. I think we could untangle these issues if we decided
that we liked this kind of release id.
>
> I don't think we should have JIRA referring to any external releases
> made by anyone. But it would be nice in JIRA to be able exactly
> refer to a point in a branch, even if it is not released yet. This
> way a bug could be logged that say is a regression to the unreleased
> branch but does not affect changes before X. Currently I just add
> comments saying the regression happened with change # xxxxx, but it
> would be better to be able to update the jira affects version field
> with something exact. For instance this could allow someone how wants to
> make an official apache release to run a query and decide to make it
> include changes up to X release id but not everything as there is an
> outstanding issue.
>
>
Re: Bumping the fourth digit
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Given other's input it seems like it might cause too much problem
to change either to lower number of digits and/or to include the
build number in the last digit. I'd rather not cause more confusion
for users with any change, especially a change that goes into a
released branch. I don't think there is any need to tie it to a
specific external release, point release, or anything. It is merely
a change to the branch that allows one to correctly identify using
sysinfo the version that contains all previous changes to the branch.
It may cause some confusion as there will be release id's that don't
match up with apache releases, but we already get those when we go
through the standard release voting process and decide to throw out
one release in place for the next one.
So I would go with the original proposal and allow any committer to
bump the 4th number after any change in a branch. It probably would
be useful to also promote the build number to be as easily retrievable
as any of the 4 digits. I think someone in the discussion said it
some cases it was not as easily available as the version number. Would
be nice if we get a JIRA out there identifying this problem.
/mikem
Dag H. Wanvik wrote:
> I think we should try to keep this simple; bump the last digit when
> somebody requests it on the branch to make a point referenceable (it
> could be an external release, or a release candidate, or whatever). I
> sort of like Mike's suggestion of doing it for every commit on the
> branch, but I understand that could upset some expectations and may be
> too radical.
>
> Dag
>
Re: Bumping the fourth digit
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
I think we should try to keep this simple; bump the last digit when
somebody requests it on the branch to make a point referenceable (it
could be an external release, or a release candidate, or whatever). I
sort of like Mike's suggestion of doing it for every commit on the
branch, but I understand that could upset some expectations and may be
too radical.
Dag
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Mike Matrigali wrote:
> I don't have a problem with allowing 4th digit bumps to any branch
> by any committer. If someone wanted to bump this with every change
> I also would not have a problem. As Kathey mentioned this would
> force a query recompile for every fix which might be safer, rather
> than force someone to remember it if the fix required the recompile.
> Even if there is not an official apache release
> it can help the discussion between developers working on their own
> builds off the branch to better exactly describe the code they are
> working. The svn build number included helps with this but some
> tools and applications just deal with the 4 part version number more
> naturally.
>
> Should we just change the build process to make the 4th digit
> the build number, ie. the svn number of the last change included
> in the build? This would give an exact release id for every
> change and not require manual intervention. Does this break something?
> I know some process requires one of these numbers to be 0 to force
> a bets.
>
> I don't think we should have JIRA referring to any external releases
> made by anyone. But it would be nice in JIRA to be able exactly
> refer to a point in a branch, even if it is not released yet. This
> way a bug could be logged that say is a regression to the unreleased
> branch but does not affect changes before X. Currently I just add
> comments saying the regression happened with change # xxxxx, but it
> would be better to be able to update the jira affects version field
> with something exact. For instance this could allow someone how wants to
> make an official apache release to run a query and decide to make it
> include changes up to X release id but not everything as there is an
> outstanding issue.
>
>
What if we added a new JIRA field to supplement the "affects version"
field? The new field could be a short text box for recording specific
subversion commit-stamps. This could be blank for issues filed against
official releases but could be useful for identifying other points on
the community branches.
Regards,
-Rick
Re: Bumping the fourth digit
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
>
> I am beginning to wonder about whether we really need 4 part release
> ids. It seems to me that a distribution is uniquely identified by a
> branch id (10.1, 10.2, etc.) plus a subversion commit-stamp. So to
> continue with Kathey's example, the following release id contains all
> the information we need: 10.3.706492.
>
I am uncomfortable with changing the version string in this way,
especially on the release branches. I am also uncomfortable even in
changing it as Mike suggested. I think I know some users that explicitly
expect and parse the 4 part version string. If you like I can check
with them, but I would rather not go down this path if we can avoid it.
Kathey
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Mike Matrigali wrote:
> I don't have a problem with allowing 4th digit bumps to any branch
> by any committer. If someone wanted to bump this with every change
> I also would not have a problem. As Kathey mentioned this would
> force a query recompile for every fix which might be safer, rather
> than force someone to remember it if the fix required the recompile.
> Even if there is not an official apache release
> it can help the discussion between developers working on their own
> builds off the branch to better exactly describe the code they are
> working. The svn build number included helps with this but some
> tools and applications just deal with the 4 part version number more
> naturally.
>
> Should we just change the build process to make the 4th digit
> the build number, ie. the svn number of the last change included
> in the build? This would give an exact release id for every
> change and not require manual intervention. Does this break something?
> I know some process requires one of these numbers to be 0 to force
> a bets.
>
> I don't think we should have JIRA referring to any external releases
> made by anyone. But it would be nice in JIRA to be able exactly
> refer to a point in a branch, even if it is not released yet. This
> way a bug could be logged that say is a regression to the unreleased
> branch but does not affect changes before X. Currently I just add
> comments saying the regression happened with change # xxxxx, but it
> would be better to be able to update the jira affects version field
> with something exact. For instance this could allow someone how wants to
> make an official apache release to run a query and decide to make it
> include changes up to X release id but not everything as there is an
> outstanding issue.
I am beginning to wonder about whether we really need 4 part release
ids. It seems to me that a distribution is uniquely identified by a
branch id (10.1, 10.2, etc.) plus a subversion commit-stamp. So to
continue with Kathey's example, the following release id contains all
the information we need: 10.3.706492.
Regards,
-Rick
>
>
Re: Bumping the fourth digit
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I don't have a problem with allowing 4th digit bumps to any branch
by any committer. If someone wanted to bump this with every change
I also would not have a problem. As Kathey mentioned this would
force a query recompile for every fix which might be safer, rather
than force someone to remember it if the fix required the recompile.
Even if there is not an official apache release
it can help the discussion between developers working on their own
builds off the branch to better exactly describe the code they are
working. The svn build number included helps with this but some
tools and applications just deal with the 4 part version number more
naturally.
Should we just change the build process to make the 4th digit
the build number, ie. the svn number of the last change included
in the build? This would give an exact release id for every
change and not require manual intervention. Does this break something?
I know some process requires one of these numbers to be 0 to force
a bets.
I don't think we should have JIRA referring to any external releases
made by anyone. But it would be nice in JIRA to be able exactly
refer to a point in a branch, even if it is not released yet. This
way a bug could be logged that say is a regression to the unreleased
branch but does not affect changes before X. Currently I just add
comments saying the regression happened with change # xxxxx, but it
would be better to be able to update the jira affects version field with
something exact. For instance this could allow someone how wants to
make an official apache release to run a query and decide to make it
include changes up to X release id but not everything as there is an
outstanding issue.
Re: Bumping the fourth digit
Posted by Myrna van Lunteren <m....@gmail.com>.
I think for DERBY-3919 there was a special, technical, consideration -
the fix would not be visible unless you bumped the 4th digit...
Our normal release process is quite involved...
I think the rules for a release at Apache are, if I simplify:
- CHANGES between the last and this release need to be documented
- binaries needs to be created and signed
- binaries need to include src
- needs to be voted on and announced.
Does that seem right?
We actually have automated tests on the more recent versions - maybe
that's enough to get votes...I think getting the Changes documented,
or Release Notes, and getting everything published are the hardest
part of the release process.
Another way to handle bumping of the digit is to limit it to when
either blockers or critical bugs are being backported...Or every 20th
backport...Just throwing ideas out.
Thoughts?
Myrna
Re: Bumping the fourth digit
Posted by Kathey Marsden <km...@sbcglobal.net>.
One thing I thought might be worth mentioning, (or it may just muddy
things more) is that for years I have had success giving users builds
that are clearly marked with the the build number (e.g. presenting the
build as 10.3.3.1.706492 instead of just 10.3.3.1). The only real
problem this ever caused was the case where generated code changed and
we needed the version bump for SPS recompile.
I am still not personally adverse to bumping the fourth digit more
often, but thought I would present this as a workable alternative.
Kathey
Re: Bumping the fourth digit
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Rick Hillegas <Ri...@Sun.COM> writes:
> Jean T. Anderson wrote:
>> My actual preference here is if there's a need for release with,
>> let's say, 2 bug fixes, go ahead and release officially. :-) I would
>> think that a branch + 2 fixes (or however many) would be an easy
>> shoe-in for a release vote because all the heavy lifting was done on
>> that release for that branch.
> This would be a way forward if our release process were simpler. I
> think that our procedures are improving, but as Myrna points out in a
> later message, producing a Derby release takes a fair amount of
> time. The community process adds a minimum of 2 weeks to the
> production of a patch release. That's too long for someone who needs
> to get an emergency patch to a customer.
It could work, though. Whoever needs to ship an emergency fix to a
customer could still do that with the release candidate while the
community is voting over it. Even if the release candidate is rejected
by the community, the version number will match a well-defined point on
the branch (and in JIRA), just like any other rejected release
candidate.
--
Knut Anders
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Jean T. Anderson wrote:
> Rick Hillegas wrote:
>> Jean T. Anderson wrote:
>>> Rick Hillegas wrote:
>>>> Jean T. Anderson wrote:
>>>>> Kathey Marsden wrote:
>>>>>> Rick Hillegas wrote:
>>>>>>>
>>>>>>> As a test of this, I have updated the description of 10.4.2.1.
>>>>>>> You can see this by clicking on the link you forwarded. Does
>>>>>>> this format look reasonable to you?
>>>>>>>
>>>>>> I think we cannot include an url to the Sun build in Jira.
>>>>>> According to:
>>>>>> http://www.apache.org/dev/release.html
>>>>>>
>>>>>> "Do not include any links on the project website that might
>>>>>> encourage non-developers to download and use nightly builds,
>>>>>> snapshots, release candidates, or any other similar package.
>>>>>> ...
>>>>>> Under no circumstances are unapproved builds a substitute for
>>>>>> releases. If this policy seems inconvenient, then release more
>>>>>> often. Proper release management is a key aspect of Apache
>>>>>> software development.
>>>>>>
>>>>> That www.apache.org/dev/release.html policy governs distribution
>>>>> of software produced by an Apache project and made available for
>>>>> download from an Apache website.
>>>>>
>>>>> Why are we concerned about tracking releases produced by
>>>>> non-Apache entities, such as Sun?
>>>> And IBM. And anyone else who wants to build a distribution from the
>>>> community branches. We're talking about tracking and fixing bugs
>>>> which are logged against commit points on a community codeline,
>>>> whether that is the development mainline or one of our stable
>>>> branches. This is useful to everyone who drinks out of the common
>>>> well.
>>>>
>>>
>>> but it doesn't make sense for an apache project to reference
>>> somebody else's external (non-Apache) build or distribution.
>>> --That's a slippery slope that would then need to accommodate
>>> anybody who comes along. And we should never bump the Derby release
>>> number to accommodate an external project.
>> Hi Jean,
>>
>> If you need to fix bugs in the metadata queries, then you have to
>> bump the last digit of the release id in order to coax Derby into
>> recompiling the queries. This is what IBM did to fix DERBY-3919.
>> Committers fix bugs all the time in order to accommodate external
>> projects. Do you believe that the community has agreed to a
>> limitation on updates to the last digit of the release id, and if so,
>> what are those limitations?
>>
>
> I think I'm not quite understanding the fundamental issue here. I
> have no problem with Sun tech support finding a problem, doing the
> fix, and committing it to Apache. Or IBM doing the same thing. Or Joe
> WhomEver from Company X.
>
> The issue is if any external entity fixes something in their own
> distro that hasn't been contributed back to apache yet, they're on
> their own. I don't think we should accommodate that. But rereading
> this, I don't think this is what you intended and I misunderstood. I'm
> sorry.
No need to apologize. I think the issues are still a bit tangled and
we're all muddling through this together.
>
> Sun effectively released from the 10.4.2 branch to include a fix that
> is in that branch at Apache, but "10.4.2" isn't specific enough to
> identify what comprises that release. Is this right? :-)
That's right. We're talking about bugs that were fixed in the open and
patches that were checked into the community codeline..
>
> In this case, I agree that we might want to consider bumping the digit
> on a per-request basis, but I want to make sure that we do this in a
> way that makes general sense. And I also realize that this might
> conceivably leave us open to criticism that we are enabling support
> for unofficial releases.
A couple more thoughts:
1) It helps me to separate the version id in the branch from the version
id in JIRA. I would have no problem with bumping the 4th digit of the
branch id every time someone checked a bugfix into the branch. I'm not
saying I want to do this, I'm just saying that it wouldn't bother me.
2) It would seem simpler to me if we had generic release ids in JIRA,
like "10.3.next" and "10.4.next". The meaning of these ids is "the next
release vehicle created from that branch". We don't really know what the
release id will be until we've generated a couple release candidates and
at that point, the release manager has to bulk-reassign the "fixed-in"
field anyway.
3) Then there is the question of how to mark issues whose fixes appear
in distributions which were created outside the community even though
the distributions were created from community codelines. Is this
information which the community should track?
4) There's also the question of how to log bugs which surface in one of
these external distributions. These are bugs in the community code and
everyone benefits from knowing about these bugs and from their fixes.
What should we put in the "affects version" field? How do we signal what
the subversion commit-stamp is--the bug-fixer may need this information.
It seems to me that the main sources of bug reports are:
a) Bugs arising in official Derby releases which users have downloaded
from the Apache website
b) Bugs arising in Cloudscape releases. If I understand correctly, these
releases roll up additional bug fixes on top of what appear in the
community distributions. That is, these distributions represent a
subversion commit-stamp further along the branch than the corresponding
community release.
c) Bugs arising in Java DB releases whose bits are identical to official
Derby releases and whose subversion commit-stamps are identical to
community releases.
d) Bugs arising in Java DB releases which roll up additional bug fixes,
like the Cloudscape releases.
>
> My actual preference here is if there's a need for release with, let's
> say, 2 bug fixes, go ahead and release officially. :-) I would think
> that a branch + 2 fixes (or however many) would be an easy shoe-in for
> a release vote because all the heavy lifting was done on that release
> for that branch.
This would be a way forward if our release process were simpler. I think
that our procedures are improving, but as Myrna points out in a later
message, producing a Derby release takes a fair amount of time. The
community process adds a minimum of 2 weeks to the production of a patch
release. That's too long for someone who needs to get an emergency patch
to a customer.
Thanks,
-Rick
>
> -jean
>
>
Re: Bumping the fourth digit
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Rick Hillegas wrote:
> Jean T. Anderson wrote:
>> Rick Hillegas wrote:
>>> Jean T. Anderson wrote:
>>>> Kathey Marsden wrote:
>>>>> Rick Hillegas wrote:
>>>>>>
>>>>>> As a test of this, I have updated the description of 10.4.2.1.
>>>>>> You can see this by clicking on the link you forwarded. Does this
>>>>>> format look reasonable to you?
>>>>>>
>>>>> I think we cannot include an url to the Sun build in Jira.
>>>>> According to:
>>>>> http://www.apache.org/dev/release.html
>>>>>
>>>>> "Do not include any links on the project website that might
>>>>> encourage non-developers to download and use nightly builds,
>>>>> snapshots, release candidates, or any other similar package.
>>>>> ...
>>>>> Under no circumstances are unapproved builds a substitute for
>>>>> releases. If this policy seems inconvenient, then release more
>>>>> often. Proper release management is a key aspect of Apache
>>>>> software development.
>>>>>
>>>> That www.apache.org/dev/release.html policy governs distribution of
>>>> software produced by an Apache project and made available for
>>>> download from an Apache website.
>>>>
>>>> Why are we concerned about tracking releases produced by non-Apache
>>>> entities, such as Sun?
>>> And IBM. And anyone else who wants to build a distribution from the
>>> community branches. We're talking about tracking and fixing bugs
>>> which are logged against commit points on a community codeline,
>>> whether that is the development mainline or one of our stable
>>> branches. This is useful to everyone who drinks out of the common well.
>>>
>>
>> but it doesn't make sense for an apache project to reference somebody
>> else's external (non-Apache) build or distribution. --That's a
>> slippery slope that would then need to accommodate anybody who comes
>> along. And we should never bump the Derby release number to
>> accommodate an external project.
> Hi Jean,
>
> If you need to fix bugs in the metadata queries, then you have to bump
> the last digit of the release id in order to coax Derby into
> recompiling the queries. This is what IBM did to fix DERBY-3919.
> Committers fix bugs all the time in order to accommodate external
> projects. Do you believe that the community has agreed to a limitation
> on updates to the last digit of the release id, and if so, what are
> those limitations?
>
I think I'm not quite understanding the fundamental issue here. I have
no problem with Sun tech support finding a problem, doing the fix, and
committing it to Apache. Or IBM doing the same thing. Or Joe WhomEver
from Company X.
The issue is if any external entity fixes something in their own distro
that hasn't been contributed back to apache yet, they're on their own. I
don't think we should accommodate that. But rereading this, I don't
think this is what you intended and I misunderstood. I'm sorry.
Sun effectively released from the 10.4.2 branch to include a fix that is
in that branch at Apache, but "10.4.2" isn't specific enough to identify
what comprises that release. Is this right? :-)
In this case, I agree that we might want to consider bumping the digit
on a per-request basis, but I want to make sure that we do this in a way
that makes general sense. And I also realize that this might conceivably
leave us open to criticism that we are enabling support for unofficial
releases.
My actual preference here is if there's a need for release with, let's
say, 2 bug fixes, go ahead and release officially. :-) I would think
that a branch + 2 fixes (or however many) would be an easy shoe-in for a
release vote because all the heavy lifting was done on that release for
that branch.
-jean
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Jean T. Anderson wrote:
> Rick Hillegas wrote:
>> Jean T. Anderson wrote:
>>> Kathey Marsden wrote:
>>>> Rick Hillegas wrote:
>>>>>
>>>>> As a test of this, I have updated the description of 10.4.2.1. You
>>>>> can see this by clicking on the link you forwarded. Does this
>>>>> format look reasonable to you?
>>>>>
>>>> I think we cannot include an url to the Sun build in Jira.
>>>> According to:
>>>> http://www.apache.org/dev/release.html
>>>>
>>>> "Do not include any links on the project website that might
>>>> encourage non-developers to download and use nightly builds,
>>>> snapshots, release candidates, or any other similar package.
>>>> ...
>>>> Under no circumstances are unapproved builds a substitute for
>>>> releases. If this policy seems inconvenient, then release more
>>>> often. Proper release management is a key aspect of Apache software
>>>> development.
>>>>
>>> That www.apache.org/dev/release.html policy governs distribution of
>>> software produced by an Apache project and made available for
>>> download from an Apache website.
>>>
>>> Why are we concerned about tracking releases produced by non-Apache
>>> entities, such as Sun?
>> And IBM. And anyone else who wants to build a distribution from the
>> community branches. We're talking about tracking and fixing bugs
>> which are logged against commit points on a community codeline,
>> whether that is the development mainline or one of our stable
>> branches. This is useful to everyone who drinks out of the common well.
>>
>
> but it doesn't make sense for an apache project to reference somebody
> else's external (non-Apache) build or distribution. --That's a
> slippery slope that would then need to accommodate anybody who comes
> along. And we should never bump the Derby release number to
> accommodate an external project.
Hi Jean,
If you need to fix bugs in the metadata queries, then you have to bump
the last digit of the release id in order to coax Derby into recompiling
the queries. This is what IBM did to fix DERBY-3919. Committers fix bugs
all the time in order to accommodate external projects. Do you believe
that the community has agreed to a limitation on updates to the last
digit of the release id, and if so, what are those limitations?
Thanks,
-Rick
>
> -jean
>
>> Regards,
>> -Rick
>>>
>>> -jean
>>>
>>>> Just the subversion commit number should be sufficient in the Jira
>>>> version comment I think.
>>>>
>>>>
>>>> Kathey
>>>>
>>>
>>
>
Re: Bumping the fourth digit
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Rick Hillegas wrote:
> Jean T. Anderson wrote:
>> Kathey Marsden wrote:
>>> Rick Hillegas wrote:
>>>>
>>>> As a test of this, I have updated the description of 10.4.2.1. You
>>>> can see this by clicking on the link you forwarded. Does this
>>>> format look reasonable to you?
>>>>
>>> I think we cannot include an url to the Sun build in Jira.
>>> According to:
>>> http://www.apache.org/dev/release.html
>>>
>>> "Do not include any links on the project website that might
>>> encourage non-developers to download and use nightly builds,
>>> snapshots, release candidates, or any other similar package.
>>> ...
>>> Under no circumstances are unapproved builds a substitute for
>>> releases. If this policy seems inconvenient, then release more
>>> often. Proper release management is a key aspect of Apache software
>>> development.
>>>
>> That www.apache.org/dev/release.html policy governs distribution of
>> software produced by an Apache project and made available for
>> download from an Apache website.
>>
>> Why are we concerned about tracking releases produced by non-Apache
>> entities, such as Sun?
> And IBM. And anyone else who wants to build a distribution from the
> community branches. We're talking about tracking and fixing bugs which
> are logged against commit points on a community codeline, whether that
> is the development mainline or one of our stable branches. This is
> useful to everyone who drinks out of the common well.
>
but it doesn't make sense for an apache project to reference somebody
else's external (non-Apache) build or distribution. --That's a slippery
slope that would then need to accommodate anybody who comes along. And
we should never bump the Derby release number to accommodate an external
project.
-jean
> Regards,
> -Rick
>>
>> -jean
>>
>>> Just the subversion commit number should be sufficient in the Jira
>>> version comment I think.
>>>
>>>
>>> Kathey
>>>
>>
>
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Jean T. Anderson wrote:
> Kathey Marsden wrote:
>> Rick Hillegas wrote:
>>>
>>> As a test of this, I have updated the description of 10.4.2.1. You
>>> can see this by clicking on the link you forwarded. Does this format
>>> look reasonable to you?
>>>
>> I think we cannot include an url to the Sun build in Jira. According
>> to:
>> http://www.apache.org/dev/release.html
>>
>> "Do not include any links on the project website that might encourage
>> non-developers to download and use nightly builds, snapshots, release
>> candidates, or any other similar package.
>> ...
>> Under no circumstances are unapproved builds a substitute for
>> releases. If this policy seems inconvenient, then release more often.
>> Proper release management is a key aspect of Apache software
>> development.
>>
> That www.apache.org/dev/release.html policy governs distribution of
> software produced by an Apache project and made available for download
> from an Apache website.
>
> Why are we concerned about tracking releases produced by non-Apache
> entities, such as Sun?
And IBM. And anyone else who wants to build a distribution from the
community branches. We're talking about tracking and fixing bugs which
are logged against commit points on a community codeline, whether that
is the development mainline or one of our stable branches. This is
useful to everyone who drinks out of the common well.
Regards,
-Rick
>
> -jean
>
>> Just the subversion commit number should be sufficient in the Jira
>> version comment I think.
>>
>>
>> Kathey
>>
>
Re: Bumping the fourth digit
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
>>
>> As a test of this, I have updated the description of 10.4.2.1. You
>> can see this by clicking on the link you forwarded. Does this format
>> look reasonable to you?
>>
> I think we cannot include an url to the Sun build in Jira. According to:
> http://www.apache.org/dev/release.html
>
> "Do not include any links on the project website that might encourage
> non-developers to download and use nightly builds, snapshots, release
> candidates, or any other similar package.
> ...
> Under no circumstances are unapproved builds a substitute for
> releases. If this policy seems inconvenient, then release more often.
> Proper release management is a key aspect of Apache software development.
>
That www.apache.org/dev/release.html policy governs distribution of
software produced by an Apache project and made available for download
from an Apache website.
Why are we concerned about tracking releases produced by non-Apache
entities, such as Sun?
-jean
> Just the subversion commit number should be sufficient in the Jira
> version comment I think.
>
>
> Kathey
>
Re: Bumping the fourth digit
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
>
> As a test of this, I have updated the description of 10.4.2.1. You can
> see this by clicking on the link you forwarded. Does this format look
> reasonable to you?
>
I think we cannot include an url to the Sun build in Jira. According to:
http://www.apache.org/dev/release.html
"Do not include any links on the project website that might encourage
non-developers to download and use nightly builds, snapshots, release
candidates, or any other similar package.
...
Under no circumstances are unapproved builds a substitute for releases.
If this policy seems inconvenient, then release more often. Proper
release management is a key aspect of Apache software development.
Just the subversion commit number should be sufficient in the Jira
version comment I think.
Kathey
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
>> Where should be track that association of external releases with
>> subversion commit-stamps? On the wiki? In a special JIRA entry?
>>
> I think when you create a version, you can put in a comment which is
> displayed here:
> https://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:versions-panel
>
>
> Can these comments be edited? If so, we could update them with the
> final subversion commit for the version.
Hi Kathey,
This is a great place to hang this information. You can edit the
comments on the release id by going in through JIRA's Administrator tab,
selecting Derby, selecting Manage Versions, then clicking the "edit"
link on the version you're interested in.
As a test of this, I have updated the description of 10.4.2.1. You can
see this by clicking on the link you forwarded. Does this format look
reasonable to you?
Thanks,
-Rick
>
> Kathey
>
>
>
Re: Bumping the fourth digit
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> Where should be track that association of external releases with
> subversion commit-stamps? On the wiki? In a special JIRA entry?
>
I think when you create a version, you can put in a comment which is
displayed here:
https://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:versions-panel
Can these comments be edited? If so, we could update them with the
final subversion commit for the version.
Kathey
Re: Bumping the fourth digit
Posted by Rick Hillegas <Ri...@Sun.COM>.
Knut Anders Hatlen wrote:
> Kathey Marsden <km...@sbcglobal.net> writes:
>
>
>> Myrna van Lunteren wrote:
>>
>>> Maybe we can simply follow a policy that whenever someone needs it,
>>> the fourth digit can be bumped?
>>> Like, a request to derby-dev, so the JIRA administrators can add a
>>> version? The person requesting the bump should ensure JIRA's affected
>>> have the correct version #.
>>>
>>> This would make fourth digit a kind of informal patch level, but we'd
>>> not necessarily save the builds.
>>>
>>> Opinions?
>>>
>>>
>>>
>> I think that sounds ok. I agree the Jira fix version should match
>> sysinfo, so whoever is making the unofficial patch level should bump
>> the version immediately after making the jars they plan to hand out in
>> preparation for the next round.
>>
>
> Sounds good to me too. For a new release on the branch we bump the third
> digit and reset the fourth digit, so bumping the fourth digit more
> frequently than we currently do shouldn't have any impact on the version
> number for any upcoming (official) release.
>
>
I think this is a reasonable accommodation for people who donate fixes
back to the community and who have to give real customers emergency
patches faster than the community can operate. However, I think that the
community needs to know the subversion commit-stamps of these external
distributions--otherwise these release ids are not meaningful to JIRA.
Where should be track that association of external releases with
subversion commit-stamps? On the wiki? In a special JIRA entry?
Thanks,
-Rick
Re: Bumping the fourth digit
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> Myrna van Lunteren wrote:
>> Maybe we can simply follow a policy that whenever someone needs it,
>> the fourth digit can be bumped?
>> Like, a request to derby-dev, so the JIRA administrators can add a
>> version? The person requesting the bump should ensure JIRA's affected
>> have the correct version #.
>>
>> This would make fourth digit a kind of informal patch level, but we'd
>> not necessarily save the builds.
>>
>> Opinions?
>>
>>
> I think that sounds ok. I agree the Jira fix version should match
> sysinfo, so whoever is making the unofficial patch level should bump
> the version immediately after making the jars they plan to hand out in
> preparation for the next round.
Sounds good to me too. For a new release on the branch we bump the third
digit and reset the fourth digit, so bumping the fourth digit more
frequently than we currently do shouldn't have any impact on the version
number for any upcoming (official) release.
--
Knut Anders
Bumping the fourth digit (was Re: svn commit: r742512 - /db/derby/code/branches/10.4/tools/ant/properties/release.properties)
Posted by Kathey Marsden <km...@sbcglobal.net>.
Myrna van Lunteren wrote:
> Maybe we can simply follow a policy that whenever someone needs it,
> the fourth digit can be bumped?
> Like, a request to derby-dev, so the JIRA administrators can add a
> version? The person requesting the bump should ensure JIRA's affected
> have the correct version #.
>
> This would make fourth digit a kind of informal patch level, but we'd
> not necessarily save the builds.
>
> Opinions?
>
>
I think that sounds ok. I agree the Jira fix version should match
sysinfo, so whoever is making the unofficial patch level should bump the
version immediately after making the jars they plan to hand out in
preparation for the next round.
The downside is that it may confuse users, because they don't have
access to these versions referred to in Jira from the Derby site, but
they will still be listed as unreleased, so it should be ok. They can
all be merged into the real Derby release if and when there is one.
It would, of course, be best if we could have a corresponding Derby
release, so the whole community could benefit, but the overhead and the
turnaround time (at least 7 days for a vote) is just not practical. It's
too bad posting snapshots is no longer allowed.
Kathey
Re: svn commit: r742512 - /db/derby/code/branches/10.4/tools/ant/properties/release.properties
Posted by Myrna van Lunteren <m....@gmail.com>.
>
> Hi Myrna,
>
> I have backed out this change since you are not comfortable with it.
>
> Regards,
> -Rick
>
Thanks Rick...
I am not certain I got my point across.
I don't have a problem per se with bumping the fourth digit, I have a
problem with JIRA and sysinfo getting out of wack.
Maybe we can simply follow a policy that whenever someone needs it,
the fourth digit can be bumped?
Like, a request to derby-dev, so the JIRA administrators can add a
version? The person requesting the bump should ensure JIRA's affected
have the correct version #.
This would make fourth digit a kind of informal patch level, but we'd
not necessarily save the builds.
Opinions?
Myrna
Re: svn commit: r742512 -
/db/derby/code/branches/10.4/tools/ant/properties/release.properties
Posted by Rick Hillegas <Ri...@Sun.COM>.
Myrna van Lunteren wrote:
> On Mon, Feb 9, 2009 at 6:09 AM, <rh...@apache.org> wrote:
>
>> Author: rhillegas
>> Date: Mon Feb 9 14:09:56 2009
>> New Revision: 742512
>>
>> URL: http://svn.apache.org/viewvc?rev=742512&view=rev
>> Log:
>> Bump the fourth digit of the 10.4 release id.
>>
>> Modified:
>> db/derby/code/branches/10.4/tools/ant/properties/release.properties
>>
>> Modified: db/derby/code/branches/10.4/tools/ant/properties/release.properties
>> URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.4/tools/ant/properties/release.properties?rev=742512&r1=742511&r2=742512&view=diff
>> ==============================================================================
>> --- db/derby/code/branches/10.4/tools/ant/properties/release.properties (original)
>> +++ db/derby/code/branches/10.4/tools/ant/properties/release.properties Mon Feb 9 14:09:56 2009
>> @@ -15,10 +15,10 @@
>>
>> #Wed Apr 16 19:11:46 CEST 2008
>> major=10
>> -maint=2000001
>> +maint=2000002
>> drdamaint=0
>> minor=4
>> eversion=10.4
>> -copyright.comment=Copyright 1997, 2008 The Apache Software Foundation or its licensors, as applicable.
>> +copyright.comment=Copyright 1997, 2009 The Apache Software Foundation or its licensors, as applicable.
>> beta=false
>> vendor=The Apache Software Foundation
>>
>>
>>
>>
>
> Rick,
>
> I don't think you can just bump the version number like this.
>
> I understand it's confusing to customers because Sun has included a
> 10.4.2.1 build as JavaDB. But the official apache release is still
> 10.4.2.0. I saw you And added a 10.4.2.2 as fix version to one bug -
> to be consistent, you should go through all bugs that got fixed in
> 10.4 since Sun's build and mark them 10.4.2.2 also? But don't do that
> yet, let's discuss this first!
>
> Note, I don't personally have a big dependency on 10.4 at the moment,
> but it's the principle of changing policy like this.
>
> Basically, if you don't use an official Apache derby build in your
> product, then the only clue your customers have is the build number.
> I've used this approach for customers that needed bug fixes.
> Kathey and Knut briefly discussed bumping the fourth digit with
> DERBY-3919: https://issues.apache.org/jira/browse/DERBY-3919?focusedCommentId=12641912#action_12641912
> Maybe we should extend that discussion?
>
> An alternative to suddently bump the number & still minimize confusion
> for Sun's customers is to call a vote on the 10.4.2.1 as it is now.
>
> Either way, I think you should revert this change until we've discussed it.
>
> Thx,
> Myrna
>
Hi Myrna,
I have backed out this change since you are not comfortable with it.
Regards,
-Rick
Re: svn commit: r742512 - /db/derby/code/branches/10.4/tools/ant/properties/release.properties
Posted by Myrna van Lunteren <m....@gmail.com>.
On Mon, Feb 9, 2009 at 6:09 AM, <rh...@apache.org> wrote:
> Author: rhillegas
> Date: Mon Feb 9 14:09:56 2009
> New Revision: 742512
>
> URL: http://svn.apache.org/viewvc?rev=742512&view=rev
> Log:
> Bump the fourth digit of the 10.4 release id.
>
> Modified:
> db/derby/code/branches/10.4/tools/ant/properties/release.properties
>
> Modified: db/derby/code/branches/10.4/tools/ant/properties/release.properties
> URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.4/tools/ant/properties/release.properties?rev=742512&r1=742511&r2=742512&view=diff
> ==============================================================================
> --- db/derby/code/branches/10.4/tools/ant/properties/release.properties (original)
> +++ db/derby/code/branches/10.4/tools/ant/properties/release.properties Mon Feb 9 14:09:56 2009
> @@ -15,10 +15,10 @@
>
> #Wed Apr 16 19:11:46 CEST 2008
> major=10
> -maint=2000001
> +maint=2000002
> drdamaint=0
> minor=4
> eversion=10.4
> -copyright.comment=Copyright 1997, 2008 The Apache Software Foundation or its licensors, as applicable.
> +copyright.comment=Copyright 1997, 2009 The Apache Software Foundation or its licensors, as applicable.
> beta=false
> vendor=The Apache Software Foundation
>
>
>
Rick,
I don't think you can just bump the version number like this.
I understand it's confusing to customers because Sun has included a
10.4.2.1 build as JavaDB. But the official apache release is still
10.4.2.0. I saw you And added a 10.4.2.2 as fix version to one bug -
to be consistent, you should go through all bugs that got fixed in
10.4 since Sun's build and mark them 10.4.2.2 also? But don't do that
yet, let's discuss this first!
Note, I don't personally have a big dependency on 10.4 at the moment,
but it's the principle of changing policy like this.
Basically, if you don't use an official Apache derby build in your
product, then the only clue your customers have is the build number.
I've used this approach for customers that needed bug fixes.
Kathey and Knut briefly discussed bumping the fourth digit with
DERBY-3919: https://issues.apache.org/jira/browse/DERBY-3919?focusedCommentId=12641912#action_12641912
Maybe we should extend that discussion?
An alternative to suddently bump the number & still minimize confusion
for Sun's customers is to call a vote on the 10.4.2.1 as it is now.
Either way, I think you should revert this change until we've discussed it.
Thx,
Myrna