I’m willing to help as well. Do we have some kind of plan of action yet? How about setting up and Event at the DDF [0], so we can start drawing something in the sand, and dispatch action items.
Regardless, putting back up the straw man proposal from Colin, from which we can iterate. > 1.) pick a project to convert (odlparent? yangtools?) to publishing both > SNAPSHOT and release versions in this way > - Create a separated branch for all the projects we select, based off stable/boron? Or do we want to tackle that on master? I tend to think we want to do this on separate branch to avoid disruption or whatever impact this could have. > 2.) get their merge job set up (just add a second one that publishes release > versions as above) > > 3.) find a leaf project to consume them via the version range (so that > transitive dependencies don't screw things up) > - I think the dependencies report coming from autorelease can help pick up an leaf project [1] Do all the projects on which the leaf project (3) depends on has to be converted? If so, I suggest picking one with fewer dependencies to reduce to overhead. > 4.) keep working from there > > 5.) make sure our release version bump scripts don't get confused, right now > they just search for SNAPSHOT and remove it > Thanks, Alexis [0]: https://wiki.opendaylight.org/view/Events:Carbon_Dev_Forum <https://wiki.opendaylight.org/view/Events:Carbon_Dev_Forum> [1]: https://logs.opendaylight.org/releng/jenkins092/autorelease-project-report-boron/30/archives/dependencies.log.gz <https://logs.opendaylight.org/releng/jenkins092/autorelease-project-report-boron/30/archives/dependencies.log.gz> > On Aug 16, 2016, at 9:04 AM, Colin Dixon <[email protected]> wrote: > > I think, yes, it would just be a set of people willing to give some time to > drive the ball forward over time. > > --Colin > > > On Fri, Aug 12, 2016 at 7:35 AM, Vratko Polak -X (vrpolak - PANTHEON > TECHNOLOGIES at Cisco) <[email protected] <mailto:[email protected]>> wrote: > > some kind of task force > > > > What would that be? A weekly meeting, > > or just a [tag] for [email protected] > <mailto:[email protected]> > so that people can make sure they do not miss related e-mails? > > > > Vratko (willing to help on releng and integration side of things). > > > > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Colin Dixon > Sent: 11 August, 2016 17:25 > To: Michael Vorburger <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] Fast and/or Phased > Planning for the Carbon Release > > > > I think this thread is the best place to start trying to put together some > kind of task force and a plan for how we can build the tools we would need to > move to a fast and/or phased release process in the future. Namely, build the > tools during Carbon so that we could maybe use them as the primary part of > the release in Nitrogen or later. > > The obvious candidates to help with the work would be Ed, Robert and Stephen, > but we could use help. > > > > --Colin > > > > On Wed, Jul 13, 2016 at 10:00 AM, Colin Dixon <[email protected] > <mailto:[email protected]>> wrote: > > Right now, the way SNAPSHOTs work, my understanding is that we have a system > that is logically equivalent to semantic versioning where we fix the major, > minor, and patch versions, but bump the build version on every git commit and > then publish it. The result is that we could change our merge jobs to > actually publish that non-SNAPSHOT version to nexus and modify projects to > consume the version range: > > [x.y.z,x.y.z+1) > > I *think* that would wind up having the same semantics as we have today, but > have the benefits of: > > 1.) all published artifacts are immutable and explicitly named > > 2.) in theory, you could have a relatively simple local script that would let > you revert your local build to specific versions of specific artifacts > > 3.) projects could then decouple patches from published artifacts, say > merging 4 related patches in a row and not publishing an artifact until the > 4th > > The obvious disadvantages are: > > 1.) Everyone needs to move to the version range over SNAPSHOTs at once (not > quite, but close) for a given artifact > > 2.) We end up producing a lot more stuff that needs to be stored in nexus > without cleaning up > > > > Anyway, that's the straw man. The obvious way to test it would be to: > 1.) pick a project to convert (odlparent? yangtools?) to publishing both > SNAPSHOT and release versions in this way > > 2.) get their merge job set up (just add a second one that publishes release > versions as above) > > 3.) find a leaf project to consume them via the version range (so that > transitive dependencies don't screw things up) > > 4.) keep working from there > > 5.) make sure our release version bump scripts don't get confused, right now > they just search for SNAPSHOT and remove it > > > > Thoughts? > > --Colin > > > > On Tue, Jul 12, 2016 at 8:01 AM, Michael Vorburger <[email protected] > <mailto:[email protected]>> wrote: > > On a practical note, does anyone have a clearer idea how we could do > "semantic versioning combined with downstream projects using a fixed version > range" ? I'd love to see some sort of POC about that, because... I'm not yet > convinced how this is technically possible! OSGi has this idea, but what we > currently do in the build is not grab dependencies through a real OSGi > resolver (à la p2 or OBR or so), but through classic Maven - which only has > either fixed versions, or SNAPSHOT. Unless I'm missing something here. > > > > > _______________________________________________ > TSC mailing list > [email protected] <mailto:[email protected]> > https://lists.opendaylight.org/mailman/listinfo/tsc > <https://lists.opendaylight.org/mailman/listinfo/tsc>
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
