Hi Jeremy, On Fri, Dec 5, 2008 at 8:50 AM, Jeremy Bauer <[EMAIL PROTECTED]> wrote:
> Mike, > I was thinking the same thing. Providing milestone releases as an OpenJPA > published, mostly stable, tested release with clear definition of the new > function it includes. Based on Craig's observation, I don't know that > means > we have to include the -Mx- identifier in the builds though. I think it > would help us (dev) and users identify which milestone version of code is > in > development and use, but it does have obvious maintenance implications. If > we do not publish official maven releases maybe Mx it isn't required - > could > we add the Mx at the point when we do the milestone build? > There's no reason why we can't add Mx at a later time. That would be a benefit to users who always want the latest snapshot, regardless of the milestone. Users who want a specific milestone can specify the latest one from the snapshot repos (or central if we do a formal release). > > Regarding a maven publish, is it possible to publish a release to the maven > repository, say an M1 release and not branch off or create a corresponding > M1 release in JIRA? It may be useful to publish milestone releases in > maven > (for those who use maven), but not add the overhead of creating an svn > branch which we do not intend (and wouldn't make sense) to maintain. > JIRA versions and Maven releases are totally separate entities (pun not intended). Similarly a release in JIRA is not necessarily tied to a branch in SVN. I'd be inclined to publish Mx builds to the SNAPSHOT repository (less stringent checking - quicker to publish). Create a JIRA release for it (so we can track when issues crop up and when they're fixed). Create a tag in SVN for easy access, but do not create a branch. I'm open to other ideas though, -mike > > -Jeremy > > On Thu, Dec 4, 2008 at 9:50 PM, Michael Dick <[EMAIL PROTECTED]> wrote: > > > Hi Craig, > > > > I think it depends on how official we want to make the milestone > releases. > > I > > was thinking of the milestones being "smaller" convenience releases, not > > "official" releases that get published to maven central. When we cut a > > milestone release we'd leave it in the SNAPSHOT repository so that folks > > can > > test a stable(ish) version. At the same time it wouldn't be an official > > release with all the overhead and additional work that implies > (maintenance > > branch?). > > > > What do other people think? > > > > -mike > > > > > > On Thu, Dec 4, 2008 at 2:44 PM, Craig L Russell <[EMAIL PROTECTED] > > >wrote: > > > > > Hi Jeremy, > > > > > > I don't understand why the version needs to be changed from simply > > > 2.0.0-SNAPSHOT to 2.0.0-Mx-SNAPSHOT. Seems like we would be making > > trouble > > > for folks who want to use the release. Wouldn't we want to make the > > change > > > at the time we want to release, e.g. from 2.0.0-SNAPSHOT to 2.0.0-M2? > > > > > > Regards, > > > > > > Craig > > > > > > > > > On Dec 4, 2008, at 8:11 AM, Jeremy Bauer wrote: > > > > > > Three in favor, no oppose. Motion passes. :-) > > >> The build artifacts for each milestone will be named > > >> openjpa*-2.0.0-Mx-SNAPSHOT.jar, where x is the milestone number. I'll > > >> commit the pom updates for M1 shortly. > > >> > > >> -Jeremy > > >> > > >> On Wed, Dec 3, 2008 at 9:40 AM, Albert Lee <[EMAIL PROTECTED]> > wrote: > > >> > > >> +1. > > >>> > > >>> Albert Lee. > > >>> > > >>> On Wed, Dec 3, 2008 at 9:03 AM, Jeremy Bauer <[EMAIL PROTECTED]> > > >>> wrote: > > >>> > > >>> OpenJPA dev's, > > >>>> Now that we have a few iteration periods defined and are getting > > content > > >>>> into iteration 1, I think we should consider planning OpenJPA 2.0 > > >>>> > > >>> milestone > > >>> > > >>>> releases. Based on a 3 (sometimes 4) week iteration schedule and > the > > >>>> > > >>> fact > > >>> > > >>>> that it takes ~ a week to create and publish a release, how does a > > >>>> milestone > > >>>> release every other (ie. after each even numbered) iteration sound? > > If > > >>>> > > >>> we > > >>> > > >>>> discover that a milestone release every other iteration is not > > optimal, > > >>>> > > >>> we > > >>> > > >>>> can adjust as appropriate. > > >>>> > > >>>> -Jeremy > > >>>> > > >>>> > > >>> > > >>> > > >>> -- > > >>> Albert Lee. > > >>> > > >>> > > > Craig L Russell > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo > > > 408 276-5638 mailto:[EMAIL PROTECTED] > > > P.S. A good JDO? O, Gasp! > > > > > > > > >
