Community
Participate
Working Groups
BPEL is participating in Juno. IP Log has been received and forwarded to the IP team for their review.
Bob, what version number are you using for Juno? Are you sticking with 1.0? The simultaneous releases page [1] is looking for a release dated 2012-06-27 to list next to the project. Please enter a release record into the project metadata for the 1.0. [1] http://eclipse.org/projects/releases/releases.php
Actually, Bob, if you're just pushing the 1.0 bits from the May 2 review into the Juno repository without modification, a redundant release review is not required. Is this what you're doing?
There were some minor bug fixes made by Vincent and myself after the May 2 review, so...not sure if a new IP Log is necessary/required (?)
(In reply to comment #3) > There were some minor bug fixes made by Vincent and myself after the May 2 > review, so...not sure if a new IP Log is necessary/required (?) If you haven't accepted any outside contributions (i.e. all the changes have been made by existing committers), then you don't require an IP Log. If you are including something that's a little further along than 1.0 with Juno, maybe you can just call it 1.0.1, a service release, and be done with it. You don't need a review for a service release. For completeness, however, you should still enter a release record dated 2012-06-27 into the project metadata.
(In reply to comment #4) > (In reply to comment #3) > > There were some minor bug fixes made by Vincent and myself after the May 2 > > review, so...not sure if a new IP Log is necessary/required (?) > > If you haven't accepted any outside contributions (i.e. all the changes have > been made by existing committers), then you don't require an IP Log. Nope, all changes were made by committers. > If you are including something that's a little further along than 1.0 with > Juno, maybe you can just call it 1.0.1, a service release, and be done with it. A feature was "temporarily" removed to get a working build in time for the juno release. The plan is to rewrite this and get it working again in time for the next juno service release. We should probably call this 1.0.1 > You don't need a review for a service release. > > For completeness, however, you should still enter a release record dated > 2012-06-27 into the project metadata. Okey dokey.
If the bits that you're including with Juno are different from those from the last release, then you need a new version number. If you're adding functionality with the SR1 release, then the minor version will have to be incremented and a review is required.
Hi Wayne, > If the bits that you're including with Juno are different from those from the > last release, then you need a new version number. What do you mean by "last release"? Do you mean Juno M7 or Indigo (SR2)? We moved to version 1.0.0 for Juno, but no build for this version has been promoted as a release. > If you're adding functionality with the SR1 release, then the minor version > will have to be incremented and a review is required. We did not add a functionnality. We had to change the implementation of one feature because otherwise, it was not compatible with Juno (the build break arose with Juno M7 - the BPEL Designer has some legacy code, some using non-API classes). The new implementation reduced the scope of this feature but removed the use of these non-API classes. We plan to restore this scope in a later version (hopefully, for Juno SR1). And the restoration will be made so that we do not use non-API classes. Do we really need to switch to 1.0.1? I think it would make more sense to go on with 1.0.0 and move to 1.0.1 with SR1.
(In reply to comment #7) > What do you mean by "last release"? The recent (May 2/2012) 1.0.0 release. > We did not add a functionnality. > We had to change the implementation of one feature because otherwise, it was > not compatible with Juno (the build break arose with Juno M7 - the BPEL > Designer has some legacy code, some using non-API classes). I believe that this is a reasonable definition of service release. > The new > implementation reduced the scope of this feature but removed the use of these > non-API classes. We plan to restore this scope in a later version (hopefully, > for Juno SR1). And the restoration will be made so that we do not use non-API > classes. So we can say that only a subset of the release code is included in Juno. This is okay. I still don't think that a review is necessary. > > Do we really need to switch to 1.0.1? > I think it would make more sense to go on with 1.0.0 and move to 1.0.1 with > SR1. If the bits are different from 1.0.0, then it is by definition a service release.
>> What do you mean by "last release"? > The recent (May 2/2012) 1.0.0 release. OK, we will switch to 1.0.1.
Created attachment 216517 [details] Approved IP Log
Since you're including a service release with Juno, a release review is not required. I'm marking this bug as INVALID.
