On 20/02/2019 14:17, [email protected] wrote: > Hi all > > > > Than Ha, I got the same question on another thread so thank you for the > clarifications. > > > > Here is my feedback. > > If SM projects are affected by the branch lock of Managed projects > because of Gerrit limitations, I think this is problematic, not only > from a schedule standpoint. > > If I am not mistaken, Jenkins releng macros are only available on > predefined branches. This means Neon CI/CD can only be installed there > and new changes can really be tested in the stable/neon branch. > > This really complicates the integration work. > > I noticed also that target dependencies versions are stabilized 1 or 2 > days just before the branch lock. Afterwards, there are a couple of > weeks where SNAPSHOT and non-SNAPSHOT versions continue to coexist.
Snapshot artifacts are pruned if they are not refreshed in three weeks.
I think snapshot versions of artifacts should be pruned when
corresponding release artifacts are promoted, but I don't know whether
that is technically possible.
> I perfectly understand that not all project and subproject versions can
> be documented. But since the release target doc includes non-snapshot
> and snapshot versions, even with nexus,
>
> it is complicated in such conditions to know which subproject (e.g.
> mdsal.binding.model = 1.2.6) version must be used when its version is
> non-aligned with the parent project version (e.g. mdsal.binding-parent
> =3.0.6).
I disagree. The only versions you need to care about are the versions of:
- ${project}-artifacts
- any parent poms produced by a project
All of these are version-aligned in mdsal, currently at 3.0.6.
Individual versions of artifacts are communicated through
mdsal-artifacts-3.0.6 and you should be getting them by:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.opendaylight.mdsal</groupId>
<artifactId>mdsal-artifacts</artifactId>
<version>3.0.6</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
This is documented in
https://wiki.opendaylight.org/view/CrossProject:HouseKeeping_Best_Practices_Group:Project_layout
and has been the recommended way of consuming artifacts downstream for
more than 3 years.
If there is an artifact produced by a project and it is not part of
${project}-artifacts, that needs to be reported to upstream, as it
either is a bug, or that artifact is not meant for downstream consumption.
If you are not using the above to get version declarations, then yes, it
is complicated, but that is a complication you are inflicting on yourself.
Regards,
Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
