> 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]] 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]<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.
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
