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
