> yangtools will stay permanently out of autorelease > and further integration with the Simultaneous Release process > will be strictly done on released versions of yangtools artifacts, > with yangtools releases running ahead of SR > and potentially supporting multiple SRs.
>From Releng/Builder point of view, one consequence is that master branch can be built with special stream "master", which signifies there should be no downstream jobs. As I missed previous Odlparent job evolution (see [0], [1], [2]), I added a longer comment to [3]. Vratko. [0] https://git.opendaylight.org/gerrit/59293 [1] https://git.opendaylight.org/gerrit/61940 [2] https://git.opendaylight.org/gerrit/59690 [3] https://git.opendaylight.org/gerrit/#/c/63837/4/jjb/yangtools/yangtools.yaml@12 -----Original Message----- From: controller-dev-boun...@lists.opendaylight.org [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga Sent: 3 August, 2017 02:12 To: yangtools-...@lists.opendaylight.org; rele...@lists.opendaylight.org Cc: netconf-...@lists.opendaylight.org; t...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org Subject: [controller-dev] Nitrogen M5: yangtools branching/versioning strategy Hello everyone, sorry for the cross-post, but I want to make sure this reaches the largest audience possible. We have passed Nitrogen offset-0 M5, which means we are officially code-frozen. The only exceptions to this are: - bugfixes not requiring breaking API changes - API deprecation patches - documentation improvements - patches fixing Sonar issues One exception is whatever we need to fix bugs 5824/5825 -- this may not need signature changes, but may change behavior, which is an API change. The exact details will be hashed out with NETCONF next week. The next significant milestone is Nitrogen offset-2 M5, at which point we can expect branch cut to happen -- and we need something unusual to happen w.r.t. yangtools: - Nitrogen stability branch name should be v1.2.x - yangtoools versions on master need to be bumped in non-trivial way: - all artifacts with 1.x.x-SNAPSHOT need to be bumped to 2.0.0-SNAPSHOT - all artifacts wint 0.x.x-SNAPSHOT need to be bumped to 1.0.0-SNAPSHOT - all downstreams on their stable/nitrogen branch will be bumped as usual - all downstreams on their master branch will be bumped to Nitrogen-released versions of yangtools (i.e. yangtools-artifacts-1.2.0) The reason for this is that yangtools is following semantic versioning and we have to make API changes to address the following: 0) remove all @Deprecated elements 1) clean up the mess left behind by YANG 1.1 semantics changes to yang-model-api 2) finally get rid of the notion that a Model automatically has a YANG text source 3) prepare for Guava dropping CheckedFuture 4) migrate completely to java.util.Optional and friends 5) redefine YangInstanceIdentifier.AugmentationIdentifier (as being just another name for QNameModule) 6) get rid of @Nullable in core APIs 7) sort out the 'revision is a Date' mess 8) finish splitting up yang-parser-impl and others which I have not looked for yet. Scope will need to be limited so we do not suffer from the second-system effect -- we clearly cannot make all the changes we would want to (like addressing all that comes from RFC7950 not differentiating between semantic and encoding representation of data). Most of these changes are trivial for downstreams to consume, but 2) and 5) have non-trivial effects on downstreams: mdsal is affected by 2), as during maven build it needs to be able to cross-reference effective module name and the resource name where that input file will end up being for purposes of $YangModuleInfo. This affects yang-maven-plugin-spi -- I think we have all the bits ready, but they need to be finised. The impact of 5) is two-fold: A) mdsal is impacted the most, as it needs to implement mapping of datastore transactions between unaligned access models B) all downstream users using the data store are impacted where a single model (with its submodels) defines multiple augments to the same target node. The data store will no longer treat these objects as separate enitities, but as parts of the same entity, potentially tripping up MVCC conflicts Preliminary target for delivering yangtools-2.0.0-RC0 would be for Oxygen offset-0 M3, which I think will happen around October/November. I am not sure if we can complete the changes in time for that or whether mdsal and downstreams will be able to integrate 2.0.0 in time for a smooth Oxygen SR. If downstream integration proves to be difficult, we will need to re-target reintegration to Fluorine M0/M1. Another concern is exposing odlparent-3.0.0 to downstreams in Oxygen time frame, which needs to be integrated very soon in the release cycle -- sooner than we can be ready for our 2.0.0. For these purposes, once odlparent-3.0.0 is released, we will branch yangtools to 'v1.3.x' from the contents of v1.2.x branch. Downstreams will therefore be switching from 1.2.x (where x corresponds to last Nitrogen SR released at that point) to 1.3.0-SNAPSHOT as part of their odlparent-3.0.0 adoption process. yangtools master will receive odlparent-3.0.0 at the same time. The mode of operation of v1.3.x will be determined when that branch is created -- I think we can deliver some features/enhancements on that release train, if the need arises. After our downstreams adopt 2.0.x, yangtools will stay permanently out of autorelease and further integration with the Simultaneous Release process will be strictly done on released versions of yangtools artifacts, with yangtools releases running ahead of SR and potentially supporting multiple SRs. Can the Release Engineering team explicitly ACK of being ready for Nitrogen stable branching as outlined above? Any other thoughts? Regards, Robert _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
