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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
