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]> wrote: > > some kind of task force > > > > What would that be? A weekly meeting, > > or just a [tag] for [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:tsc-bounces@lists. > opendaylight.org] *On Behalf Of *Colin Dixon > *Sent:* 11 August, 2016 17:25 > *To:* Michael Vorburger <[email protected]> > *Cc:* [email protected]; [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]> > 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]> > 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. > > >
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
