Preparing to cut the 10.4 branch
We have now passed the feature freeze point (2008-03-08 00:00 GMT-12) and I have started to look for a suitable revision from which to cut the branch. My subversion client reports times using the CET (GMT+1) timezone so if my math is correct all revisions created prior to 2008-03-08 13:00 CET should be on the branch. This means that the earilest revision which can be used for branching is r634896 | mikem | 2008-03-08 04:52:19 +0100 (Sat, 08 Mar 2008) | 6 lines DERBY-3456 Clean up comments and adjust newly added code to match style of surrounding code. There appears to have been 3 checkins after that: r634993 | djd | 2008-03-08 17:00:27 +0100 (Sat, 08 Mar 2008) | 1 line DERBY-2109 Minor cleanup of the security code added for system permissions to ch ange methods not to be public, add a minor comment and fix a file header r635115 | djd | 2008-03-09 00:56:05 +0100 (Sun, 09 Mar 2008) | 2 lines DERBY-3435 Implements a new test class for the NetworkServerMBean and adds it to the management test suite. All attributes are tested, although testing of the a ctual attribute values could be improved (see code comments). Attribute names an d return types are always tested. Contributed by John H. Embretsen Email: John dot Embretsen at Sun dot com r635183 | kahatlen | 2008-03-09 08:33:41 +0100 (Sun, 09 Mar 2008) | 16 lines DERBY-2911: Implement a buffer manager using java.util.concurrent classes DERBY-3493: stress.multi times out waiting on testers with blocked testers waiti ng on the same statement Changed ConcurrentCache.create() to match Clock.create() more closely. The patch basically makes ConcurrentCache.create() use ConcurrentHashMap.get() directly instead of going through ConcurrentCache.getEntry(), which may block until the identity has been set by another thread. Then create() fails immediately if the object already exists in the cache, also if another thread is in the process of inserting the object into the cache. Since this introduced yet another difference between find() and create() in findOrCreateObject(), I also followed ?\195?\152ystein's suggestion from his review of DERBY-2911 and split findOrCreateObject() into a number of smaller methods, which I think makes the code easier to follow. They all seem like bug fixes that would need to be merged to the new branch so unless I hear otherwise, I plan to cut the branch(es) from revision 635183. I plan to do this early on Monday (CET). Thanks, -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: > They all seem like bug fixes that would need to be merged to the new branch > so unless I hear otherwise, I plan to cut the branch(es) from revision > 635183. > > I plan to do this early on Monday (CET). Done: r635491 | dyre | 2008-03-10 09:59:34 +0100 (Mon, 10 Mar 2008) | 1 line Created 10.4 source branch r635492 | dyre | 2008-03-10 10:00:21 +0100 (Mon, 10 Mar 2008) | 1 line Created 10.4 doc branch The wiki page for how to bump the version number on trunk was a bit out-dated, but I think I got it to work. I'm currently running the tests to make sure. Will commit the version bump as soon as they have finished (if everything is ok). -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: > [EMAIL PROTECTED] writes: > >> They all seem like bug fixes that would need to be merged to the new branch >> so unless I hear otherwise, I plan to cut the branch(es) from revision >> 635183. >> >> I plan to do this early on Monday (CET). > The wiki page for how to bump the version number on trunk was a bit > out-dated, but I think I got it to work. I'm currently running the tests > to make sure. Will commit the version bump as soon as they have finished > (if everything is ok). r63 | dyre | 2008-03-10 14:46:28 +0100 (Mon, 10 Mar 2008) | 2 lines Bumping the minor version number on trunk. New version number is 10.5. Those who follow the Wiki updates closely will have seen that my understanding has changed throughout the day :( http://wiki.apache.org/db-derby/DerbySnapshotOrRelease describes my current understanding of the version bumping process. Please comment if I have messed something up. The update of the maint property on the 10.4 branch will hopefully happen soon... -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre
Re: Preparing to cut the 10.4 branch
On 3/10/08, Dyre Tjeldvoll <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > > > The update of the maint property on the 10.4 branch will hopefully > > happen soon... > > > There... > > > r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines > > Updating the maint property on the 10.4 branch > > > > I ran the tests successfully (on the 10.4 branch), but I did not modify > the beta flag. Should I? And do I still need to update the master files > if/when I do that? > > Dyre > re master files: I removed the need for updating master files with DERBY-3088. Myrna
Re: Preparing to cut the 10.4 branch
Dyre Tjeldvoll wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre Hi Dyre, When you run sysinfo on the branch, what version number does it report? Thanks, -Rick
Re: Preparing to cut the 10.4 branch
Myrna van Lunteren wrote: On 3/10/08, Dyre Tjeldvoll <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre re master files: I removed the need for updating master files with DERBY-3088. Thanks. I'll update the Wiki to reflect this. Dyre
Re: Preparing to cut the 10.4 branch
Rick Hillegas wrote: Dyre Tjeldvoll wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre Hi Dyre, When you run sysinfo on the branch, what version number does it report? Thanks, -Rick 10.4.0.1 I believe... Dyre
Re: Preparing to cut the 10.4 branch
Dyre Tjeldvoll wrote: Rick Hillegas wrote: Dyre Tjeldvoll wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre Hi Dyre, When you run sysinfo on the branch, what version number does it report? Thanks, -Rick 10.4.0.1 I believe... Dyre Hi Dyre, When I run sysinfo against the branch, it reports that the version id is "10.4.0.1 alpha - (635685)". It think that you need to modify the 3rd digit in the release id. I believe that is the secret handshake which turns an alpha into a beta. Regards, -Rick
Re: Preparing to cut the 10.4 branch
Rick Hillegas wrote: When I run sysinfo against the branch, it reports that the version id is "10.4.0.1 alpha - (635685)". It think that you need to modify the 3rd digit in the release id. I believe that is the secret handshake which turns an alpha into a beta. The "secret handshake" is documented here: http://db.apache.org/derby/papers/versionupgrade.html Dan.
Re: Preparing to cut the 10.4 branch
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > Rick Hillegas wrote: > >> When I run sysinfo against the branch, it reports that the version >> id is "10.4.0.1 alpha - (635685)". It think that you need to modify >> the 3rd digit in the release id. I believe that is the secret >> handshake which turns an alpha into a beta. > > The "secret handshake" is documented here: > > http://db.apache.org/derby/papers/versionupgrade.html I'm sorry, but this is utterly confusing to me. tools/ant/properties/release.properties contains a property called 'beta' that can either be 'true' or 'false' The wiki page (http://wiki.apache.org/db-derby/DerbySnapshotOrRelease) talks about the 'beta flag'. You are saying that the 'beta flag' does not refer to the previously mentioned property, but to whether or not the 3rd digit of the version number (the fixpack number) is 0 or not? So when, if ever, do you modify the beta property? On the Wiki page the process of bumping the fixpack number appears to be described in the section called 'Check-ins just before generating release artifacts". But I might as well do it now, is that what you're saying? -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: > Daniel John Debrunner <[EMAIL PROTECTED]> writes: > >> Rick Hillegas wrote: >> >>> When I run sysinfo against the branch, it reports that the version >>> id is "10.4.0.1 alpha - (635685)". It think that you need to modify >>> the 3rd digit in the release id. I believe that is the secret >>> handshake which turns an alpha into a beta. >> >> The "secret handshake" is documented here: >> >> http://db.apache.org/derby/papers/versionupgrade.html > > I'm sorry, but this is utterly confusing to me. > > tools/ant/properties/release.properties contains a property called > 'beta' that can either be 'true' or 'false' > > The wiki page (http://wiki.apache.org/db-derby/DerbySnapshotOrRelease) > talks about the 'beta flag'. > > You are saying that the 'beta flag' does not refer to the previously > mentioned property, but to whether or not the 3rd digit of the version > number (the fixpack number) is 0 or not? > > So when, if ever, do you modify the beta property? > > On the Wiki page the process of bumping the fixpack number appears to be > described in the section called 'Check-ins just before generating > release artifacts". > > But I might as well do it now, is that what you're saying? I did some experimenting, and here are the results: Alt A: With maint=001 and beta=true 10.4.0.1 alpha - (635861) Alt B: With maint=001 and beta=false 10.4.0.1 alpha - (635861M) Alt C: With maint=101 and beta=true 10.4.1.1 beta - (635861M) Alt D: With maint=101 and beta=false 10.4.1.1 - (635861M) So I thought alt. A was correct for the period from when the branch is cut up to the point when the first RC is spun (targetted for 2008-04-04), alt. C for the RC and alt. D for the final release. But based on the comments I take it that I should go immediately to alt. C, and that alt. D should be used for the RC. If someone confirms this I can check in the change to release.properties and update the Wiki. Thanks, -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: > I did some experimenting, and here are the results: > Alt A: > With maint=001 and beta=true > 10.4.0.1 alpha - (635861) > > Alt B: > With maint=001 and beta=false > 10.4.0.1 alpha - (635861M) > > Alt C: > With maint=101 and beta=true > 10.4.1.1 beta - (635861M) > > Alt D: > With maint=101 and beta=false > 10.4.1.1 - (635861M) > > So I thought alt. A was correct for the period from when the branch is > cut up to the point when the first RC is spun (targetted for > 2008-04-04), alt. C for the RC and alt. D for the final release. The release candidate should not have the beta flag. As long as it has the beta flag it can't be released and therefore cannot be a candidate for release... :) > But based on the comments I take it that I should go immediately to alt. > C, and that alt. D should be used for the RC. If someone confirms this > I can check in the change to release.properties and update the Wiki. Sounds reasonable to me. Although I had expected the last digit to be 0, not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember). -- Knut Anders
Re: Preparing to cut the 10.4 branch
Knut Anders Hatlen <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > >> I did some experimenting, and here are the results: >> Alt A: >> With maint=001 and beta=true >> 10.4.0.1 alpha - (635861) >> >> Alt B: >> With maint=001 and beta=false >> 10.4.0.1 alpha - (635861M) >> >> Alt C: >> With maint=101 and beta=true >> 10.4.1.1 beta - (635861M) >> >> Alt D: >> With maint=101 and beta=false >> 10.4.1.1 - (635861M) >> >> So I thought alt. A was correct for the period from when the branch is >> cut up to the point when the first RC is spun (targetted for >> 2008-04-04), alt. C for the RC and alt. D for the final release. > > The release candidate should not have the beta flag. As long as it has > the beta flag it can't be released and therefore cannot be a candidate > for release... :) > >> But based on the comments I take it that I should go immediately to alt. >> C, and that alt. D should be used for the RC. If someone confirms this >> I can check in the change to release.properties and update the Wiki. > > Sounds reasonable to me. Although I had expected the last digit to be 0, > not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember). I don't know why it shouldn't be 0. But following the old instructions on the Wiki (either by running maintversion2props directly, or by doing ant bumplastdigit in tools/relase, which seems to be doing the same thing) I ended up with the last digit being 1... If it should in fact, be 0, then I have to ask that someone tells me exaclty what to do, step by step, so that I can re-write the Wiki from scratch... -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: > Knut Anders Hatlen <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED] writes: >> >>> I did some experimenting, and here are the results: >>> Alt A: >>> With maint=001 and beta=true >>> 10.4.0.1 alpha - (635861) >>> >>> Alt B: >>> With maint=001 and beta=false >>> 10.4.0.1 alpha - (635861M) >>> >>> Alt C: >>> With maint=101 and beta=true >>> 10.4.1.1 beta - (635861M) >>> >>> Alt D: >>> With maint=101 and beta=false >>> 10.4.1.1 - (635861M) >>> >>> So I thought alt. A was correct for the period from when the branch is >>> cut up to the point when the first RC is spun (targetted for >>> 2008-04-04), alt. C for the RC and alt. D for the final release. >> >> The release candidate should not have the beta flag. As long as it has >> the beta flag it can't be released and therefore cannot be a candidate >> for release... :) >> >>> But based on the comments I take it that I should go immediately to alt. >>> C, and that alt. D should be used for the RC. If someone confirms this >>> I can check in the change to release.properties and update the Wiki. >> >> Sounds reasonable to me. Although I had expected the last digit to be 0, >> not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember). > > I don't know why it shouldn't be 0. But following the old instructions > on the Wiki (either by running maintversion2props directly, or by doing > ant bumplastdigit in tools/relase, which seems to be doing the same > thing) I ended up with the last digit being 1... > > If it should in fact, be 0, then I have to ask that someone tells me > exaclty what to do, step by step, so that I can re-write the Wiki from > scratch... I haven't followed the steps on the wiki myself, but by reading it, it seems like this is what should happen with the version numbers: 1. After creating the branch, "ant bumplastdigit" (step 5 under "Prepare the community for a new release") will change the version from 10.4.0.0 to 10.4.0.1. This sounds OK as it will help us distinguish between 10.4 on the trunk and 10.4 on the branch. 2. Before creating the first release candidate, update both the third and the fourth digit of the version number by updating the maint property in tools/ant/properties/release.properties, and set the beta property in the same file to false. After this step, the version number shuld be 10.4.1.0. 3. Before creating subsequent release candidates, update the fourth digit (either by manually updating release.properties or by running "ant bumplastdigit"). After this step, the version number should be 10.4.1.1, 10.4.1.2, ... The wiki page does not distinguish between (2) and (3), it only says this under "Check-ins just before generating release artifacts": > Bump the version number, adjust the beta flag and check in the new > version. > > The third and fourth parts of the version are combined into a > single property, maint, where maint = (third digit * 100) + > fourth digit. Also, if this is a major/minor (feature) release, > you should remove the beta flag at this time. You should update > tools/ant/properties/release.properties by hand and then run: So according to this paragraph, you should edit release.property by hand, and then you can set maint to whichever number you'd like before you run maintversion2props. -- Knut Anders
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: Knut Anders Hatlen <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] writes: I did some experimenting, and here are the results: Alt A: With maint=001 and beta=true 10.4.0.1 alpha - (635861) Alt B: With maint=001 and beta=false 10.4.0.1 alpha - (635861M) Alt C: With maint=101 and beta=true 10.4.1.1 beta - (635861M) Alt D: With maint=101 and beta=false 10.4.1.1 - (635861M) So I thought alt. A was correct for the period from when the branch is cut up to the point when the first RC is spun (targetted for 2008-04-04), alt. C for the RC and alt. D for the final release. The release candidate should not have the beta flag. As long as it has the beta flag it can't be released and therefore cannot be a candidate for release... :) But based on the comments I take it that I should go immediately to alt. C, and that alt. D should be used for the RC. If someone confirms this I can check in the change to release.properties and update the Wiki. Sounds reasonable to me. Although I had expected the last digit to be 0, not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember). I don't know why it shouldn't be 0. But following the old instructions on the Wiki (either by running maintversion2props directly, or by doing ant bumplastdigit in tools/relase, which seems to be doing the same thing) I ended up with the last digit being 1... If it should in fact, be 0, then I have to ask that someone tells me exaclty what to do, step by step, so that I can re-write the Wiki from scratch... Hi Dyre, This part of our release process seems to trip up every new release manager and the instructions could use some improvement. My understanding of bumplastdigit is this: you run it after you generate a candidate and it sets up the release id for the next candidate. In any event, with or without bumping the last digit, option (C) produces a release id that looks good to me. Thanks, -Rick
Re: Preparing to cut the 10.4 branch
Rick Hillegas <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: >> Knut Anders Hatlen <[EMAIL PROTECTED]> writes: >> >> >>> [EMAIL PROTECTED] writes: >>> >>> I did some experimenting, and here are the results: Alt A: With maint=001 and beta=true 10.4.0.1 alpha - (635861) Alt B: With maint=001 and beta=false 10.4.0.1 alpha - (635861M) Alt C: With maint=101 and beta=true 10.4.1.1 beta - (635861M) Alt D: With maint=101 and beta=false 10.4.1.1 - (635861M) > Hi Dyre, > > This part of our release process seems to trip up every new release > manager and the instructions could use some improvement. My > understanding of bumplastdigit is this: you run it after you generate > a candidate and it sets up the release id for the next candidate. In > any event, with or without bumping the last digit, option (C) produces > a release id that looks good to me. OK, so your vote goes to C': With maint=100 and beta=true 10.4.1.0 beta - (635861M) ? -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: Daniel John Debrunner <[EMAIL PROTECTED]> writes: Rick Hillegas wrote: When I run sysinfo against the branch, it reports that the version id is "10.4.0.1 alpha - (635685)". It think that you need to modify the 3rd digit in the release id. I believe that is the secret handshake which turns an alpha into a beta. The "secret handshake" is documented here: http://db.apache.org/derby/papers/versionupgrade.html I'm sorry, but this is utterly confusing to me. tools/ant/properties/release.properties contains a property called 'beta' that can either be 'true' or 'false' The wiki page (http://wiki.apache.org/db-derby/DerbySnapshotOrRelease) talks about the 'beta flag'. You are saying that the 'beta flag' does not refer to the previously mentioned property, but to whether or not the 3rd digit of the version number (the fixpack number) is 0 or not? No, to quote the document: "Fixpack (f) of 0 (zero) is a special value that indicates alpha quality software and causes version string to be appended with the word "alpha"." Thus the third digit being 0 always marks the software as alpha, regardless of any setting of the beta flag, it overrides it. Dan.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: Rick Hillegas <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] wrote: Knut Anders Hatlen <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] writes: I did some experimenting, and here are the results: Alt A: With maint=001 and beta=true 10.4.0.1 alpha - (635861) Alt B: With maint=001 and beta=false 10.4.0.1 alpha - (635861M) Alt C: With maint=101 and beta=true 10.4.1.1 beta - (635861M) Alt D: With maint=101 and beta=false 10.4.1.1 - (635861M) Hi Dyre, This part of our release process seems to trip up every new release manager and the instructions could use some improvement. My understanding of bumplastdigit is this: you run it after you generate a candidate and it sets up the release id for the next candidate. In any event, with or without bumping the last digit, option (C) produces a release id that looks good to me. OK, so your vote goes to C': With maint=100 and beta=true 10.4.1.0 beta - (635861M) ? Hi Dyre, To me that looks like a good id for a beta candidate. +1. Regards, -Rick
Re: Preparing to cut the 10.4 branch
Knut Anders Hatlen <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > >> Knut Anders Hatlen <[EMAIL PROTECTED]> writes: >> >>> [EMAIL PROTECTED] writes: >>> I did some experimenting, and here are the results: Alt A: With maint=001 and beta=true 10.4.0.1 alpha - (635861) Alt B: With maint=001 and beta=false 10.4.0.1 alpha - (635861M) Alt C: With maint=101 and beta=true 10.4.1.1 beta - (635861M) Alt D: With maint=101 and beta=false 10.4.1.1 - (635861M) > I haven't followed the steps on the wiki myself, but by reading it, it > seems like this is what should happen with the version numbers: > > 1. After creating the branch, "ant bumplastdigit" (step 5 under > "Prepare the community for a new release") will change the version > from 10.4.0.0 to 10.4.0.1. This sounds OK as it will help us > distinguish between 10.4 on the trunk and 10.4 on the branch. Keep in mind that I have edited that page several times in the last couple of days, so you need to look at an older version to see what it originally said... The original version did not mention the 'ant bumplastdigit' target. I added that beacuse I thought it superseded the old 'ant regex.masters' target which no longer exists... > 2. Before creating the first release candidate, update both the third > and the fourth digit of the version number by updating the maint > property in tools/ant/properties/release.properties, and set the > beta property in the same file to false. After this step, the > version number shuld be 10.4.1.0. This is the same as the C' alternative proposed by Rick isn't it? Seems like Rick favors going directly to your step 2. > 3. Before creating subsequent release candidates, update the fourth > digit (either by manually updating release.properties or by running > "ant bumplastdigit"). After this step, the version number should be > 10.4.1.1, 10.4.1.2, ... Agreed. > The wiki page does not distinguish between (2) and (3), it only says > this under "Check-ins just before generating release artifacts": > >> Bump the version number, adjust the beta flag and check in the new >> version. >> >> The third and fourth parts of the version are combined into a >> single property, maint, where maint = (third digit * 100) + >> fourth digit. Also, if this is a major/minor (feature) release, >> you should remove the beta flag at this time. You should update >> tools/ant/properties/release.properties by hand and then run: > > So according to this paragraph, you should edit release.property by > hand, and then you can set maint to whichever number you'd like before > you run maintversion2props. Agreed. But I don't see what the purpose of the maintversion2props program is (other than implementing ant bumplastdigit). Seems to me you could achieve exactly the same thing by just editing release.properties by hand... I would like to change the Wiki so that each step of the release process becomes a cookbook, that the RM can follow. Specifically, I would like to remove implicit dependencies on steps described elsewhere, even if that should lead to some duplication. -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: I would like to change the Wiki so that each step of the release process becomes a cookbook, that the RM can follow. or that could be implemented in an ant script ... Dan.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: >> 2. Before creating the first release candidate, update both the third >> and the fourth digit of the version number by updating the maint >> property in tools/ant/properties/release.properties, and set the >> beta property in the same file to false. After this step, the >> version number shuld be 10.4.1.0. > > This is the same as the C' alternative proposed by Rick isn't it? Seems > like Rick favors going directly to your step 2. No, the C' alternative didn't set the beta flag to false. I think it is OK to leave the beta flag for now, but it should be set to false before you create the first release candidate. I don't have any strong opinions on whether you should bump the version from 10.4.0.1 to 10.4.1.0 now or later. -- Knut Anders
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: >> 2. Before creating the first release candidate, update both the third >> and the fourth digit of the version number by updating the maint >> property in tools/ant/properties/release.properties, and set the >> beta property in the same file to false. After this step, the >> version number shuld be 10.4.1.0. > > This is the same as the C' alternative proposed by Rick isn't it? Seems > like Rick favors going directly to your step 2. They are not really the same, since C' keeps the beta flag until the first RC is spun (thanks to Knut for pointing that out). -- dt
Re: Preparing to cut the 10.4 branch
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > >> I would like to change the Wiki so that each step of the release process >> becomes a cookbook, that the RM can follow. > > or that could be implemented in an ant script ... A laudable goal to be sure... but I think I'll start with the Wiki page :) -- dt
Re: Preparing to cut the 10.4 branch
When I run sysinfo against the trunk i get, Why ? 10.5.0.0 alpha - (635600) Daniel John Debrunner-2 wrote: > > Rick Hillegas wrote: > >> When I run sysinfo against the branch, it reports that the version id is >> "10.4.0.1 alpha - (635685)". It think that you need to modify the 3rd >> digit in the release id. I believe that is the secret handshake which >> turns an alpha into a beta. > > The "secret handshake" is documented here: > >http://db.apache.org/derby/papers/versionupgrade.html > > Dan. > > -- View this message in context: http://www.nabble.com/Preparing-to-cut-the-10.4-branch-tp15928311p15976672.html Sent from the Apache Derby Developers mailing list archive at Nabble.com.
Re: Preparing to cut the 10.4 branch
fp wrote: When I run sysinfo against the trunk i get, Why ? 10.5.0.0 alpha - (635600) 10.5 because with the creation of the 10.4 branch, trunk becomes the development line for the next release (10.5). alpha because the third digit is zero and the trunk is leading edge development, see: http://db.apache.org/derby/dev/derby_source.html#Development+trunk Dan.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: They all seem like bug fixes that would need to be merged to the new branch so unless I hear otherwise, I plan to cut the branch(es) from revision 635183. Can you confirm that 635183 was the revision base for the branch? Thanks, Dan.
Re: Preparing to cut the 10.4 branch
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > >> They all seem like bug fixes that would need to be merged to the new branch >> so unless I hear otherwise, I plan to cut the branch(es) from revision >> 635183. > > Can you confirm that 635183 was the revision base for the branch? Seems like it. $ svn log -v --stop-on-copy https://svn.apache.org/repos/asf/db/derby/code/branches/10.4 | tail Updating the maint property on the 10.4 branch r635491 | dyre | 2008-03-10 09:59:34 +0100 (Mon, 10 Mar 2008) | 1 line Changed paths: A /db/derby/code/branches/10.4 (from /db/derby/code/trunk:635183) Created 10.4 source branch -- Knut Anders
Re: Preparing to cut the 10.4 branch
Daniel John Debrunner <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > >> They all seem like bug fixes that would need to be merged to the new branch >> so unless I hear otherwise, I plan to cut the branch(es) from revision >> 635183. > > Can you confirm that 635183 was the revision base for the branch? Yes. -- dt
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: > Daniel John Debrunner <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED] wrote: >> >>> They all seem like bug fixes that would need to be merged to the new branch >>> so unless I hear otherwise, I plan to cut the branch(es) from revision >>> 635183. >> >> Can you confirm that 635183 was the revision base for the branch? > > Yes. I have updated http://wiki.apache.org/db-derby/DerbyTenFourRelease so that lists this and other important revisions for the branch (similar to 10.3 Wiki). I also moved the testing section up, and added some scaffolding. -- dt
