You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2005/09/19 22:45:30 UTC
10.1.2 Release status page
I put up a status page for the 10.1.2 release. Check it out for
information on the release and also how you can participate and win
*chocolate*!
http://people.apache.org/~kmarsden/TenOneTwoRelease.html
Also look at the Outstanding issues and post if you have comments.
Andrew, a couple of items on the release
1) Our filter, Derby open code bugs, seems to be available only to
derby-developers, can we make it global or at least available to users
so folks can vote for bugs they want fixed? Is there some way we can
get a direct link to the filter. The requestids in the URL's seem to
expire after some time.
2) Can we make a snapshot release this week. (Maybe tomorrow if
tonight's run is clean)? It would be good to make some of the fixes
available for early testing.
I'll post to derby-user and try to drum up more input from users once
these are available. Regarding votes on bugs, DERBY-1 is the leader
right now with 2.
Thanks
Kathey
Re: 10.1.2 Release status page
Posted by Ole Solberg <Ol...@Sun.COM>.
Daniel John Debrunner wrote:
> Jean T. Anderson wrote:
>
>
>>Ole Solberg wrote:
>>
>>
>>>I now put snapshots of our nightly builds used for regression testing on
>>>http://www.multinet.no/~solberg/public/Apache/Derby/snapshots/ .
>>
>>
>>Hi, Ole,
>>
>>I think it's terrific for you to provide these. Just one caveat. After
>>attending Cliff Schmidt's session at ApacheCon on "Licensing: What Every
>>Apache Committer Should Know", I think we need to be careful about using
>>the Apache logo on websites outside Apache unless we have obtained
>>explicit permission from the ASF to do so. Cliff went to some trouble to
>>explain that while the ASL 2.0 license allows free redistribution of
>>software, the same does not hold for trademarks and logos. Usage of
>>those require explicit permission.
>
>
> Right, the logo's make the pages look like official ASF pages, but they
> are not. They are pages provided by Sun Microsystems (or is it Ole
> Solberg?).
>
> Which leads me to the statement on the pages that says:
>
> "Derby is intended to be the Java alternative to low-cost open source
> databases."
>
> I'm troubled by that, I don't see anything in the Derby charter that
> leads to that statement, and "Derby is intended" is strange, Derby is a
> lump of Java code, I don't think it has intentions. The first statement
> you have is fine "Derby is an open source, 100% Java SQL Database",
> that's factual and in line with the charter.
>
Cleaned up now...
> Now it may be that you or your employer has that intention for Derby,
> and that's an acceptable thing to have on such a page.
>
> E.g. <company> intends Derby to to be the Java alternative to low-cost
> open source databases.
>
> [don't want to put the real name there cause it might get quoted and I
> have no idea if that would be a true statement or not].
>
> As Jean said, it's great to have these nightly builds and tests, and we
> can link to them from the ASF Derby site, but the links need to say
>
> testing results kindly provided by Sun Microsystems
>
> nightly builds kindly provided by Sun Microsystems
>
> Thanks,
> Dan.
>
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: 10.1.2 Release status page
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jean T. Anderson wrote:
> Ole Solberg wrote:
>
>> I now put snapshots of our nightly builds used for regression testing on
>> http://www.multinet.no/~solberg/public/Apache/Derby/snapshots/ .
>
>
> Hi, Ole,
>
> I think it's terrific for you to provide these. Just one caveat. After
> attending Cliff Schmidt's session at ApacheCon on "Licensing: What Every
> Apache Committer Should Know", I think we need to be careful about using
> the Apache logo on websites outside Apache unless we have obtained
> explicit permission from the ASF to do so. Cliff went to some trouble to
> explain that while the ASL 2.0 license allows free redistribution of
> software, the same does not hold for trademarks and logos. Usage of
> those require explicit permission.
Right, the logo's make the pages look like official ASF pages, but they
are not. They are pages provided by Sun Microsystems (or is it Ole
Solberg?).
Which leads me to the statement on the pages that says:
"Derby is intended to be the Java alternative to low-cost open source
databases."
I'm troubled by that, I don't see anything in the Derby charter that
leads to that statement, and "Derby is intended" is strange, Derby is a
lump of Java code, I don't think it has intentions. The first statement
you have is fine "Derby is an open source, 100% Java SQL Database",
that's factual and in line with the charter.
Now it may be that you or your employer has that intention for Derby,
and that's an acceptable thing to have on such a page.
E.g. <company> intends Derby to to be the Java alternative to low-cost
open source databases.
[don't want to put the real name there cause it might get quoted and I
have no idea if that would be a true statement or not].
As Jean said, it's great to have these nightly builds and tests, and we
can link to them from the ASF Derby site, but the links need to say
testing results kindly provided by Sun Microsystems
nightly builds kindly provided by Sun Microsystems
Thanks,
Dan.
Re: 10.1.2 Release status page
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Jean T. Anderson wrote:
> ...
> I'll see if Cliff has made his presentation available anywhere
> ...
Cliff's presentation, ""Licensing: What Every Apache Committer Should
Know" is now available off this link:
http://wiki.apache.org/apachecon/Eu2005OnlineSessionSlides
cheers,
-jean
Re: 10.1.2 Release status page
Posted by Ole Solberg <Ol...@Sun.COM>.
Jean T. Anderson wrote:
> Ole Solberg wrote:
>
>> I now put snapshots of our nightly builds used for regression testing on
>> http://www.multinet.no/~solberg/public/Apache/Derby/snapshots/ .
>
>
> Hi, Ole,
>
> I think it's terrific for you to provide these. Just one caveat. After
> attending Cliff Schmidt's session at ApacheCon on "Licensing: What Every
> Apache Committer Should Know", I think we need to be careful about using
> the Apache logo on websites outside Apache unless we have obtained
> explicit permission from the ASF to do so. Cliff went to some trouble to
> explain that while the ASL 2.0 license allows free redistribution of
> software, the same does not hold for trademarks and logos. Usage of
> those require explicit permission.
Thanks a lot! I have now removed all references to the logos.
>
> I'll see if Cliff has made his presentation available anywhere and, if
> not, ask if he'd mind me making it available on the derby site.
>
> -jean
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: 10.1.2 Release status page
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Ole Solberg wrote:
> I now put snapshots of our nightly builds used for regression testing on
> http://www.multinet.no/~solberg/public/Apache/Derby/snapshots/ .
Hi, Ole,
I think it's terrific for you to provide these. Just one caveat. After
attending Cliff Schmidt's session at ApacheCon on "Licensing: What Every
Apache Committer Should Know", I think we need to be careful about using
the Apache logo on websites outside Apache unless we have obtained
explicit permission from the ASF to do so. Cliff went to some trouble to
explain that while the ASL 2.0 license allows free redistribution of
software, the same does not hold for trademarks and logos. Usage of
those require explicit permission.
I'll see if Cliff has made his presentation available anywhere and, if
not, ask if he'd mind me making it available on the derby site.
-jean
Re: 10.1.2 Release status page
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Ole Solberg wrote:
> I now put snapshots of our nightly builds used for regression testing on
> http://www.multinet.no/~solberg/public/Apache/Derby/snapshots/ .
>
> There is a link to this page from
> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/index.html
> (Tested Revisions [Jar files]).
>
> For each build / snapshot(zipped jar files) there is a link to the test
> results for that build.
Great, could you replace the term 'snapshot' with nightly build. I think
'snapshot' at the ASF is somewhere between a nightly build and a release.
Also could you have some info on how the jars were built (I think
releases and snapshots need this also), e.g. which jdk & compiler, does
it include the optional J2ME and OSGi elements.
Dan.
Re: 10.1.2 Release status page
Posted by Ole Solberg <Ol...@Sun.COM>.
I now put snapshots of our nightly builds used for regression testing on
http://www.multinet.no/~solberg/public/Apache/Derby/snapshots/ .
There is a link to this page from
http://www.multinet.no/~solberg/public/Apache/Derby/Limited/index.html
(Tested Revisions [Jar files]).
For each build / snapshot(zipped jar files) there is a link to the test
results for that build.
David W. Van Couvering wrote:
> I was putting nightly builds on the back burner, but if this is
> something you could use for the release, let me know.
>
> I was thinking of putting the nightly builds directory directly under
> the Derby web site area under people.apache.org, with a directory for
> eah build. Isn't it automatically mirrored every six hours or so?
> Anyway, your guidance on the right approach is appreciated.
>
> David
>
> Andrew McIntyre wrote:
>
>>
>> On Sep 19, 2005, at 1:45 PM, Kathey Marsden wrote:
>>
>>> 1) Our filter, Derby open code bugs, seems to be available only to
>>> derby-developers, can we make it global or at least available to users
>>> so folks can vote for bugs they want fixed?
>>
>>
>>
>> It is now global. I don't think there's a way to link directly to the
>> filter. It looks like you'll have to point users to the Manage
>> Filters page:
>>
>> http://issues.apache.org/jira/secure/ManageFilters.jspa
>>
>> From which they can click on the Derby open code bugs filter link.
>>
>>> 2) Can we make a snapshot release this week. (Maybe tomorrow if
>>> tonight's run is clean)? It would be good to make some of the fixes
>>> available for early testing.
>>
>>
>>
>> Sure, although wouldn't it be preferable to get nightly builds going?
>> I think David was going to do that, David let me know if you need
>> help with the details on how to automatically push things to the
>> website.
>>
>> andrew
>>
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
Re: 10.1.2 Release status page
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
David W. Van Couvering wrote:
> ...
> I was thinking of putting the nightly builds directory directly under
> the Derby web site area under people.apache.org, with a directory for
> eah build. Isn't it automatically mirrored every six hours or so?
Currently stuff in /www/ on people.apache.org gets rsync'd hourly to the
apache web server that hosts db.apache.org. (This is different from the
mirrors system -- didn't want anyone to get confused.)
-jean
Re: 10.1.2 Release status page
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I was putting nightly builds on the back burner, but if this is
something you could use for the release, let me know.
I was thinking of putting the nightly builds directory directly under
the Derby web site area under people.apache.org, with a directory for
eah build. Isn't it automatically mirrored every six hours or so?
Anyway, your guidance on the right approach is appreciated.
David
Andrew McIntyre wrote:
>
> On Sep 19, 2005, at 1:45 PM, Kathey Marsden wrote:
>
>> 1) Our filter, Derby open code bugs, seems to be available only to
>> derby-developers, can we make it global or at least available to users
>> so folks can vote for bugs they want fixed?
>
>
> It is now global. I don't think there's a way to link directly to the
> filter. It looks like you'll have to point users to the Manage Filters
> page:
>
> http://issues.apache.org/jira/secure/ManageFilters.jspa
>
> From which they can click on the Derby open code bugs filter link.
>
>> 2) Can we make a snapshot release this week. (Maybe tomorrow if
>> tonight's run is clean)? It would be good to make some of the fixes
>> available for early testing.
>
>
> Sure, although wouldn't it be preferable to get nightly builds going? I
> think David was going to do that, David let me know if you need help
> with the details on how to automatically push things to the website.
>
> andrew
>
Re: 10.1.2 Release status page
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Sorry .... Not fourth, third .
> I think fourth version number should be increased when program was officialy released ,
> because rc-X is not yet program of the version officialy acknowledged .
I think third version number should be increased when program was officialy released ,
because rc-X is not yet program of the version officialy acknowledged .
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, September 24, 2005 11:25 PM
Subject: Re: 10.1.2 Release status page
> Hello.
>
> I feel it strange that version number was decreased between rc-X and released version ......
>
> I think fourth version number should be increased when program was officialy released ,
> because rc-X is not yet program of the version officialy acknowledged .
>
> // Or preparing special version number ,such as 10.1.2.r0 10.1.2.r1 ... , for rc version may be better ....
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
> tmnk@apache.org
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "Daniel John Debrunner" <dj...@debrunners.com>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, September 21, 2005 10:28 PM
> Subject: Re: 10.1.2 Release status page
>
>
>> Andrew McIntyre wrote:
>>
>>>
>>> On Sep 20, 2005, at 8:18 PM, Daniel John Debrunner wrote:
>>>
>>>> I would say that if the version of the 10.1 branch is 10.1.1.1 then a
>>>> fix should result in the bug being marked as fixed in '10.1.1.1
>>>> (unreleased version)'. Ie. correctly represent the version of when the
>>>> bug was fixed.
>>>>
>>>> Once 10.1.2 is released (or maybe a release candidate) then any bugs
>>>> fixed in 10.1 since the last release could *also* be marked fixed in
>>>> '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This
>>>> additional fixin is to link the bugs with the release and helps the
>>>> release notes generation.
>>>
>>>
>>> My only problem with this is that eventually you will end up with scores
>>> of unreleased versions in the bug tracking system. If we're not ever
>>> planning on releasing that version, why bother having a number for it at
>>> all? Why not just bump the version on the branch to 10.1.2.0 now and
>>> start marking all of the bugs fixed in 10.1.2.0, since we've already
>>> agreed that that's the next version we're actually going to officially
>>> release?
>>
>> Good points, but remember that we (the Derby project) may not be the
>> only group making a release. Anyone, this being open source, can make a
>> version of Derby for their own purposes, e.g. to redistribute within
>> their company. Thus those version numbers can represent a period of time
>> for the branch.
>>
>>>
>>>> Changing history of a bug tracking system is generally a thing to avoid.
>>>
>>>
>>> So is clogging it up with meaningless values for the version numbers.
>>
>> I don't believe they are meaningless. They represent the version of the
>> branch at some point in time which may have been used by someone.
>>
>>> The bigger issue is that we don't really know what that fourth position
>>> means. It doesn't seem to mean bugfix release, since it appears we've
>>> agreed that's what the third value represents. If we're not ever going
>>> to release a version that uses it in a meaningful way, then what is it
>>> doing there?
>>
>> For a branch I would say (using 10.1 as an example)
>>
>> - bump fourth digit at least after every snapshot, release candidate or
>> release
>> - bump third digit for the first candidate of a release
>>
>> 10.1.1.0 Initial release
>> 10.1.1.1 bumped after release
>> 10.1.1.2 bumped after snapshot (of 10.1.1.1)
>> 10.1.1.3 bumped after snapshot (of 10.1.1.2)
>> 10.1.2.0 release candicate one for 10.1.2
>> 10.1.2.1 bumped after rc1
>> rc1 goes for voting, some issues & fixes made to the branch
>> 10.1.2.1 release candicate two for 10.1.2
>> 10.1.2.2 bumped after rc2
>> rc2 accepted as official 10.1.2 release, its version is 10.1.2.1
>>
>> (and similar release candidate version changes could happen on the
>> intiial release, but I matched what is in 10.1 at the moment).
>>
>> Dan.
>>
>>
>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date: 2005/09/20
>>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
Re: 10.1.2 Release status page
Posted by Daniel John Debrunner <dj...@debrunners.com>.
TomohitoNakayama wrote:
> Hello.
>
> I may misunderstand the version number scheme ....
>
> The fourth digit of the first release for first version of specified
> third digit is not always "1" ?
Correct, it could be any value.
> If rc2 was failed and rc3 was passed in Dan's example , version number
> of released program is 10.1.2.2 ?
Could be, or could be a higher number. The sequence could go somthing
like (as an example)
10.1.2.0 - first 10.1.2 *sanpshot*
10.1.2.1 - second 10.1.2 *snapshot*
10.1.2.2 - rc1
10.1.2.3 - rc2
10.1.2.4 - rc3 and official release
Dan.
Re: 10.1.2 Release status page
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I may misunderstand the version number scheme ....
The fourth digit of the first release for first version of specified third digit is not always "1" ?
If rc2 was failed and rc3 was passed in Dan's example , version number of released program is 10.1.2.2 ?
I thought fourth digit of the first release forfirst version of specified third digit is always "1"....
Best regards .
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Kathey Marsden" <km...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, September 27, 2005 6:17 AM
Subject: Re: 10.1.2 Release status page
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> I feel it strange that version number was decreased between rc-X and
>> released version ......
>>
> I don't think we ever decrease the version. In Dan's example "10.1.2.2
> bumped after rc2" means that the version on the branch was bumped
> after rc2 was made and is done in preparation for the next release.
> rc2 was version 10.1.2.1 and would be released as is if accepted as the
> official release.
>
>> I think fourth (really meant third) version number should be
>> increased when program was officialy released , because rc-X is not
>> yet program of the version officialy acknowledged .
>>
>
> In general we bump the version when the work begins, so for example we
> bumped the trunk to 10.2 right after 10.1 branched to mark that the
> version as shown by sysinfo is 10.2 work under progress.
>
> If the last digit indicates an external release of jars (snapshot,
> release candidate, or release), then we bump it right after each post to
> the website, to indicate we are working on the next external release.
>
> Since our third digit represents only that this is a bug fix release and
> more testing has been done, then it makes sense to me bump it just
> before the release candidate is made to mark the beginning of testing.
>
>
> Kathey
>
>>>
>>> For a branch I would say (using 10.1 as an example)
>>>
>>> - bump fourth digit at least after every snapshot, release candidate or
>>> release
>>> - bump third digit for the first candidate of a release
>>>
>>> 10.1.1.0 Initial release
>>> 10.1.1.1 bumped after release
>>> 10.1.1.2 bumped after snapshot (of 10.1.1.1)
>>> 10.1.1.3 bumped after snapshot (of 10.1.1.2)
>>> 10.1.2.0 release candicate one for 10.1.2
>>> 10.1.2.1 bumped after rc1
>>> rc1 goes for voting, some issues & fixes made to the branch
>>> 10.1.2.1 release candicate two for 10.1.2
>>> 10.1.2.2 bumped after rc2
>>> rc2 accepted as official 10.1.2 release, its version is 10.1.2.1
>>>
>>> (and similar release candidate version changes could happen on the
>>> intiial release, but I matched what is in 10.1 at the moment).
>>>
>>> Dan.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date:
>>> 2005/09/20
>>>
>>
>>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date: 2005/09/26
Re: 10.1.2 Release status page
Posted by Kathey Marsden <km...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I feel it strange that version number was decreased between rc-X and
> released version ......
>
I don't think we ever decrease the version. In Dan's example "10.1.2.2
bumped after rc2" means that the version on the branch was bumped
after rc2 was made and is done in preparation for the next release.
rc2 was version 10.1.2.1 and would be released as is if accepted as the
official release.
> I think fourth (really meant third) version number should be
> increased when program was officialy released , because rc-X is not
> yet program of the version officialy acknowledged .
>
In general we bump the version when the work begins, so for example we
bumped the trunk to 10.2 right after 10.1 branched to mark that the
version as shown by sysinfo is 10.2 work under progress.
If the last digit indicates an external release of jars (snapshot,
release candidate, or release), then we bump it right after each post to
the website, to indicate we are working on the next external release.
Since our third digit represents only that this is a bug fix release and
more testing has been done, then it makes sense to me bump it just
before the release candidate is made to mark the beginning of testing.
Kathey
>>
>> For a branch I would say (using 10.1 as an example)
>>
>> - bump fourth digit at least after every snapshot, release candidate or
>> release
>> - bump third digit for the first candidate of a release
>>
>> 10.1.1.0 Initial release
>> 10.1.1.1 bumped after release
>> 10.1.1.2 bumped after snapshot (of 10.1.1.1)
>> 10.1.1.3 bumped after snapshot (of 10.1.1.2)
>> 10.1.2.0 release candicate one for 10.1.2
>> 10.1.2.1 bumped after rc1
>> rc1 goes for voting, some issues & fixes made to the branch
>> 10.1.2.1 release candicate two for 10.1.2
>> 10.1.2.2 bumped after rc2
>> rc2 accepted as official 10.1.2 release, its version is 10.1.2.1
>>
>> (and similar release candidate version changes could happen on the
>> intiial release, but I matched what is in 10.1 at the moment).
>>
>> Dan.
>>
>>
>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date:
>> 2005/09/20
>>
>
>
Re: 10.1.2 Release status page
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I feel it strange that version number was decreased between rc-X and released version ......
I think fourth version number should be increased when program was officialy released ,
because rc-X is not yet program of the version officialy acknowledged .
// Or preparing special version number ,such as 10.1.2.r0 10.1.2.r1 ... , for rc version may be better ....
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Daniel John Debrunner" <dj...@debrunners.com>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, September 21, 2005 10:28 PM
Subject: Re: 10.1.2 Release status page
> Andrew McIntyre wrote:
>
>>
>> On Sep 20, 2005, at 8:18 PM, Daniel John Debrunner wrote:
>>
>>> I would say that if the version of the 10.1 branch is 10.1.1.1 then a
>>> fix should result in the bug being marked as fixed in '10.1.1.1
>>> (unreleased version)'. Ie. correctly represent the version of when the
>>> bug was fixed.
>>>
>>> Once 10.1.2 is released (or maybe a release candidate) then any bugs
>>> fixed in 10.1 since the last release could *also* be marked fixed in
>>> '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This
>>> additional fixin is to link the bugs with the release and helps the
>>> release notes generation.
>>
>>
>> My only problem with this is that eventually you will end up with scores
>> of unreleased versions in the bug tracking system. If we're not ever
>> planning on releasing that version, why bother having a number for it at
>> all? Why not just bump the version on the branch to 10.1.2.0 now and
>> start marking all of the bugs fixed in 10.1.2.0, since we've already
>> agreed that that's the next version we're actually going to officially
>> release?
>
> Good points, but remember that we (the Derby project) may not be the
> only group making a release. Anyone, this being open source, can make a
> version of Derby for their own purposes, e.g. to redistribute within
> their company. Thus those version numbers can represent a period of time
> for the branch.
>
>>
>>> Changing history of a bug tracking system is generally a thing to avoid.
>>
>>
>> So is clogging it up with meaningless values for the version numbers.
>
> I don't believe they are meaningless. They represent the version of the
> branch at some point in time which may have been used by someone.
>
>> The bigger issue is that we don't really know what that fourth position
>> means. It doesn't seem to mean bugfix release, since it appears we've
>> agreed that's what the third value represents. If we're not ever going
>> to release a version that uses it in a meaningful way, then what is it
>> doing there?
>
> For a branch I would say (using 10.1 as an example)
>
> - bump fourth digit at least after every snapshot, release candidate or
> release
> - bump third digit for the first candidate of a release
>
> 10.1.1.0 Initial release
> 10.1.1.1 bumped after release
> 10.1.1.2 bumped after snapshot (of 10.1.1.1)
> 10.1.1.3 bumped after snapshot (of 10.1.1.2)
> 10.1.2.0 release candicate one for 10.1.2
> 10.1.2.1 bumped after rc1
> rc1 goes for voting, some issues & fixes made to the branch
> 10.1.2.1 release candicate two for 10.1.2
> 10.1.2.2 bumped after rc2
> rc2 accepted as official 10.1.2 release, its version is 10.1.2.1
>
> (and similar release candidate version changes could happen on the
> intiial release, but I matched what is in 10.1 at the moment).
>
> Dan.
>
>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date: 2005/09/20
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
Re: 10.1.2 Release status page
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
>
> On Sep 20, 2005, at 8:18 PM, Daniel John Debrunner wrote:
>
>> I would say that if the version of the 10.1 branch is 10.1.1.1 then a
>> fix should result in the bug being marked as fixed in '10.1.1.1
>> (unreleased version)'. Ie. correctly represent the version of when the
>> bug was fixed.
>>
>> Once 10.1.2 is released (or maybe a release candidate) then any bugs
>> fixed in 10.1 since the last release could *also* be marked fixed in
>> '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This
>> additional fixin is to link the bugs with the release and helps the
>> release notes generation.
>
>
> My only problem with this is that eventually you will end up with scores
> of unreleased versions in the bug tracking system. If we're not ever
> planning on releasing that version, why bother having a number for it at
> all? Why not just bump the version on the branch to 10.1.2.0 now and
> start marking all of the bugs fixed in 10.1.2.0, since we've already
> agreed that that's the next version we're actually going to officially
> release?
Good points, but remember that we (the Derby project) may not be the
only group making a release. Anyone, this being open source, can make a
version of Derby for their own purposes, e.g. to redistribute within
their company. Thus those version numbers can represent a period of time
for the branch.
>
>> Changing history of a bug tracking system is generally a thing to avoid.
>
>
> So is clogging it up with meaningless values for the version numbers.
I don't believe they are meaningless. They represent the version of the
branch at some point in time which may have been used by someone.
> The bigger issue is that we don't really know what that fourth position
> means. It doesn't seem to mean bugfix release, since it appears we've
> agreed that's what the third value represents. If we're not ever going
> to release a version that uses it in a meaningful way, then what is it
> doing there?
For a branch I would say (using 10.1 as an example)
- bump fourth digit at least after every snapshot, release candidate or
release
- bump third digit for the first candidate of a release
10.1.1.0 Initial release
10.1.1.1 bumped after release
10.1.1.2 bumped after snapshot (of 10.1.1.1)
10.1.1.3 bumped after snapshot (of 10.1.1.2)
10.1.2.0 release candicate one for 10.1.2
10.1.2.1 bumped after rc1
rc1 goes for voting, some issues & fixes made to the branch
10.1.2.1 release candicate two for 10.1.2
10.1.2.2 bumped after rc2
rc2 accepted as official 10.1.2 release, its version is 10.1.2.1
(and similar release candidate version changes could happen on the
intiial release, but I matched what is in 10.1 at the moment).
Dan.
Re: 10.1.2 Release status page
Posted by Andrew McIntyre <mc...@gmail.com>.
On Sep 20, 2005, at 8:18 PM, Daniel John Debrunner wrote:
> I would say that if the version of the 10.1 branch is 10.1.1.1 then a
> fix should result in the bug being marked as fixed in '10.1.1.1
> (unreleased version)'. Ie. correctly represent the version of when the
> bug was fixed.
>
> Once 10.1.2 is released (or maybe a release candidate) then any bugs
> fixed in 10.1 since the last release could *also* be marked fixed in
> '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This
> additional fixin is to link the bugs with the release and helps the
> release notes generation.
My only problem with this is that eventually you will end up with
scores of unreleased versions in the bug tracking system. If we're
not ever planning on releasing that version, why bother having a
number for it at all? Why not just bump the version on the branch to
10.1.2.0 now and start marking all of the bugs fixed in 10.1.2.0,
since we've already agreed that that's the next version we're
actually going to officially release?
> Changing history of a bug tracking system is generally a thing to
> avoid.
So is clogging it up with meaningless values for the version numbers.
The bigger issue is that we don't really know what that fourth
position means. It doesn't seem to mean bugfix release, since it
appears we've agreed that's what the third value represents. If we're
not ever going to release a version that uses it in a meaningful way,
then what is it doing there?
At Cloudscape, we bumped the last version whenever a fix was
delivered to a customer, which was useful because if you delivered
five fixes in a week, all five could have different version numbers
with each new version representing the next fix. However, the Apache
process for releases - posting a candidate, testing, and then voting
- prevents the kind of turnaround on quick fixes that use to make
that last position meaningful.
Perhaps we should either amend the version policy or figure out a way
to make that last number mean something useful.
andrew
Re: 10.1.2 Release status page
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
>
> Hmm, this would be my fault. The version should have been bumped after
> each release and I neglected to do that immediately after the last
> release. Also, I merged the issues with 10.1.1.1 FixIns to 10.1.2.0.
> While that was a probably a good idea, in order to target more bugs at
> the 10.1.2.0, it looks like removing the 10.1.1.1 release from JIRA
> might have been a mistake as well, since we can't mark bugs as fixed
> in 10.1.1.1.
>
> I'll bump the branch to 10.1.1.1, in preparation for posting the
> snapshot, after which I'll bump it to 10.1.1.2. If we get to 10.1.2.0
> without posting another snapshot, we can merge anything with a
> 10.1.1.2 FixIn to 10.1.2.0.
>
> Sound good?
What do you mean by "merge" in this case?
I would say that if the version of the 10.1 branch is 10.1.1.1 then a
fix should result in the bug being marked as fixed in '10.1.1.1
(unreleased version)'. Ie. correctly represent the version of when the
bug was fixed.
Once 10.1.2 is released (or maybe a release candidate) then any bugs
fixed in 10.1 since the last release could *also* be marked fixed in
'10.1.2 (released version)', not replace the fixin of 10.1.1.1. This
additional fixin is to link the bugs with the release and helps the
release notes generation.
Changing history of a bug tracking system is generally a thing to avoid.
Dan.
Re: 10.1.2 Release status page
Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/19/05, Kathey Marsden <km...@sbcglobal.net> wrote:
> Nightly builds would be nice, but a snapshot would provide a clear
> download location for users I think and at least an indication that it
> had passed regression tests, but maybe we better get the versioning
> stuff straightened out first. Our current system is problematic in
> that sysinfo output does not match our fix version and it won't really
> be clear what has been fixed in the snapshot vs the final release.
Hmm, this would be my fault. The version should have been bumped after
each release and I neglected to do that immediately after the last
release. Also, I merged the issues with 10.1.1.1 FixIns to 10.1.2.0.
While that was a probably a good idea, in order to target more bugs at
the 10.1.2.0, it looks like removing the 10.1.1.1 release from JIRA
might have been a mistake as well, since we can't mark bugs as fixed
in 10.1.1.1.
I'll bump the branch to 10.1.1.1, in preparation for posting the
snapshot, after which I'll bump it to 10.1.1.2. If we get to 10.1.2.0
without posting another snapshot, we can merge anything with a
10.1.1.2 FixIn to 10.1.2.0.
Sound good?
andrew
Re: 10.1.2 Release status page
Posted by Francois Orsini <fr...@gmail.com>.
On 9/20/05, Oyvind.Bakksjo@sun.com <Oy...@sun.com> wrote:
>
> I think the nightly build should be the build used in the testing
> reported at
> http://www.multinet.no/~solberg/public/Apache/Derby/index.html/
>
> That way, people can download and use a nightly build at their own risk,
> but they can also see what tests the build has passed/failed.
>
Sounds very good Oyvind.
Re: 10.1.2 Release status page
Posted by Oy...@Sun.COM.
Daniel John Debrunner wrote:
> Francois Orsini wrote:
>
>
>>Nightly builds should only be posted if regression tests have passed IMHO.
>
>
> I disagree, a nightly build is use at your own risk. Even if one test
> fails the jar may still work and allow anyone to test other areas.
I think the nightly build should be the build used in the testing
reported at http://www.multinet.no/~solberg/public/Apache/Derby/index.html/
That way, people can download and use a nightly build at their own risk,
but they can also see what tests the build has passed/failed.
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: 10.1.2 Release status page
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Francois Orsini wrote:
> Nightly builds should only be posted if regression tests have passed IMHO.
I disagree, a nightly build is use at your own risk. Even if one test
fails the jar may still work and allow anyone to test other areas.
Dan.
Re: 10.1.2 Release status page
Posted by Francois Orsini <fr...@gmail.com>.
Nightly builds should only be posted if regression tests have passed IMHO.
Re: 10.1.2 Release status page
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>
>> 2) Can we make a snapshot release this week. (Maybe tomorrow if
>> tonight's run is clean)? It would be good to make some of the fixes
>> available for early testing.
>
>
> Sure, although wouldn't it be preferable to get nightly builds going?
> I think David was going to do that, David let me know if you need
> help with the details on how to automatically push things to the
> website.
>
Nightly builds would be nice, but a snapshot would provide a clear
download location for users I think and at least an indication that it
had passed regression tests, but maybe we better get the versioning
stuff straightened out first. Our current system is problematic in
that sysinfo output does not match our fix version and it won't really
be clear what has been fixed in the snapshot vs the final release.
Thanks
Kathey
Re: 10.1.2 Release status page
Posted by Andrew McIntyre <mc...@gmail.com>.
On Sep 19, 2005, at 1:45 PM, Kathey Marsden wrote:
> 1) Our filter, Derby open code bugs, seems to be available only to
> derby-developers, can we make it global or at least available to users
> so folks can vote for bugs they want fixed?
It is now global. I don't think there's a way to link directly to the
filter. It looks like you'll have to point users to the Manage
Filters page:
http://issues.apache.org/jira/secure/ManageFilters.jspa
From which they can click on the Derby open code bugs filter link.
> 2) Can we make a snapshot release this week. (Maybe tomorrow if
> tonight's run is clean)? It would be good to make some of the fixes
> available for early testing.
Sure, although wouldn't it be preferable to get nightly builds going?
I think David was going to do that, David let me know if you need
help with the details on how to automatically push things to the
website.
andrew