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 <co...@colindixon.com> 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 <vorbur...@redhat.com> > 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 Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
