In regards to "semantic versioning combined with downstream projects using a fixed version range":
You have two parts to this statement: Your build uses Maven to compile bundles/features, run unit tests, etc. It'll use a specific version of a library for this purpose. Run time your bundles/features will depend on version ranges: i.e. org.foo.bar [1.0, 2.0) meaning from version 1.0 of the library up to but not including version 2.0. If you're building an application which uses org.foo.bar, than you can build with version 1.2, and link at runtime to a bundle exporting org.foo.bar with in the range 1.0 -> 2.0. Long as the API are compatible, things should work (I'll note that if 1.2 breaks compatibility, than versioning of that library should have been 2.0, or the version range should be changed to [1.0, 1.2). In regards to using P2 or OBR, please review Apache Karaf Cave's documentation. Its an OBR and repository, that's well integrated to working with Apache Karaf based systems. Apache Karaf Cave: https://karaf.apache.org/manual/cave/latest-3/ https://karaf.apache.org/manual/cave/latest-4/ On Tue, Jul 12, 2016 at 9:31 AM, Michael Vorburger <[email protected]> wrote: > I was initially, in a call a few weeks ago, a bit vocal if I remember > correctly about how I felt better project isolation with non-SNAPSHOT was > important, but meanwhile I've gotten somewhat "used to" it being how it is > in ODL, and I'm even thinking that perhaps too much isolation among projects > could become a bad thing for speed of innovation and progress in ODL's > future? > > Taking just as little examples the Checkstyle work, or a minor yangtools > performance improvement - it's actually great how everyone immediately > benefits from that the next day, through the "fast" way we currently > continuously integrate the entire kaboodle through SNAPSHOT all the time. > > If we do move to something more "phased", I'd love to see the discussion > include actual timelines we have in mind... Say if someone proposes a change > to odl-parent and yangtools, how soon / late will it be before higher up > projects like ovsdb and netvirt get to profit from them after a master > merge? A week? A month? Three months? Anything than a week would be too long > IMHO! > > And when new fixed releases of root projects such as odl-parent or yangtools > are released, then one problem we may soon face, and I've seen in other > large code bases, is that it's possible for projects to lag behind and thus > start diverge more than we'd want them re. what versions of lower depencies > they us - say, just as an example, e.g. ovsdb switching to a newer yangtools > than netvirt or some other project - this could become interesting? > Unnecessarily painful? > > 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. > > On a perhaps slightly tangential note, what is a minor PITA today is "just" > the constant re-downloading of every single org.opendaylight.* JAR > dependency, all the time. This could give some a certain feeling of slowness > in local development perhaps? I wonder if before going fully phased, there > are things that could be done to improve that? Two specific thoughts: 1. > When nothing changes 1 day in odl-parent or yangtools, do we currently still > push new SNAPSHOT every night or so? We should not. 2. Simple infra > stuff... to me download from e.g. Maven central appear faster than from > nexus.opendaylight.org, is that right? If so would looking into some sort of > CDN or a few official Mirrors, be of any value? Just a thought. > > Regards, > M. > > > Tx, > M. > -- > Michael Vorburger <[email protected]> | IRC: vorburger @freenode | ~ = > http://vorburger.ch > > On Sat, Jul 9, 2016 at 12:35 AM, Anil Vishnoi <[email protected]> wrote: >> >> I think it's a good idea to build a small team from offset-0/1/2 and try >> out the pilot. That will help us quickly to figure out the unknowns. >> Probably We should start with asking projects if they want to volunteer for >> this pilot? >> >> On Thu, Jul 7, 2016 at 6:18 AM, Colin Dixon <[email protected]> wrote: >>> >>> This has been out for two weeks without any comment, so I'll chime in a >>> bit. >>> >>> See more inline. >>> >>> --Colin >>> >>> On Thu, Jun 23, 2016 at 2:28 AM, Phil Robb <[email protected]> >>> wrote: >>>> >>>> Hello: >>>> >>>> I took an action item from the TSC to kick off a thread about >>>> potentially changing our release process for the Carbon release and what >>>> that might look like. >>>> >>>> We have had discussions for some time on shortening our release cadence >>>> from 6-8 months to something much shorter such as 2 months (Fast). This >>>> discussion often goes in conjunction with the idea of decoupling the >>>> different sets of projects that make up Offset-0, Offset-1, and Offset-2 >>>> projects, so that each of those is released separately in a staged manner >>>> (Phased). We have also talked about various methods of building >>>> OpenDaylight so that we do not have to have strict enforcement of specific >>>> versions of each project being identified for a given simultaneous release >>>> (semantic-versioning). >>>> >>>> Changing to one or more of the above release characteristics for the >>>> Carbon release is the question at hand. An immediate set of follow-up >>>> questions then are: >>>> - What projects would need to change first, and what would they need to >>>> do? >>> >>> >>> I would imagine things would have to start at the root of our dependency >>> tree with odlparent and yangtools. I would guess that semantic versioning >>> combined with downstream projects using a fixed version range instead of a >>> fixed version would be the first step, but I'd love to hear if I'm wrong >>> >>> We could have migrated projects produce both SNAPSHOTs (via the normal >>> merge job) and release artifacts (via a periodic, e.g., weekly, job and/or a >>> manual release job), so that both systems could exist side by side and >>> people could rely on either the fixed version range or SNAPSHOTs. We'd need >>> the autorelease scripts to handle that and make sure that we get the right >>> release versions of everything, but it might be pretty easy. (That does mean >>> we'd need to include releng/autorelease in the effort as well.) >>> >>> Note that while the above really talks about phased, migrated projects >>> would be free to have their own release cadence and thus be fast if they >>> wanted regardless of the simultaneous release cadence. >>> >>>> >>>> - Is there a "pilot" effort we can run to try things out, and if so, >>>> who/what are the logical people/projects to run such a pilot? >>> >>> >>> Robert and Stephen with odlparent and yangtools would seem to be the >>> logical choice. >>> >>>> >>>> - Once the initial work/pilot(s) are complete, what do all other >>>> projects have to do to make this transition work? >>> >>> >>> If we do the above and I'm right about it, nothing unless they want to. >>> >>>> >>>> - Can we get to a decision as a group our plan for this transition by >>>> the time we start the Carbon release, or is this something we need to >>>> plan/execute over a couple of release cycles before the transition is >>>> complete? >>> >>> >>> My intuition is that given where we are in the Boron release and the >>> runway we have to plan Carbon, the most we can realistically aim for in >>> Carbon would be to get a solid pilot of a few projects. >>> >>>> >>>> Please chime in with your thoughts and any corrections to the comments >>>> above. As we know from past experience it is much better to talk and >>>> decide >>>> what we're going to do in the next release cycle WELL IN ADVANCE of the >>>> completion of the current cycle. So if you have thoughts/comments on these >>>> potential changes, make them now. If we can't get to transition plan on >>>> these potential changes soon, then we'll need to put a "traditional" >>>> release >>>> plan for Carbon in place as a fall back. >>> >>> >>> I agree here. My personal take would be to post a "traditional" Carbon >>> release plan that looks like Beryllium so that we can provide fair notice >>> and time to plan for it. Then, we can have a separate fast/phased pilot >>> release plan that exists alongside it so that we can try to make progress. >>> By and large the two should be orthogonal. >>> >>>> >>>> Thanks, >>>> >>>> Phil. >>>> -- >>>> Phil Robb >>>> Sr. Director Of Technical Operations >>>> OpenDaylight Project >>>> (O) 970-229-5949 >>>> (M) 970-420-4292 >>>> Skype: Phil.Robb >>>> >>>> _______________________________________________ >>>> TSC mailing list >>>> [email protected] >>>> https://lists.opendaylight.org/mailman/listinfo/tsc >>>> >>> >>> >>> _______________________________________________ >>> TSC mailing list >>> [email protected] >>> https://lists.opendaylight.org/mailman/listinfo/tsc >>> >> >> >> >> -- >> Thanks >> Anil >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/discuss >> > > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
