AFAIK, TPCE is going to be managed from Sulfur or even Phosphorus so makes sense to consolidate to a single repo.
Yes, Silicon SR3 has shown TCPE can easily manage being an MRI project. Unimgr is irrelevant, as they still work on kernel from a few years back.
Regards, Robert
On Wed, Nov 17, 2021 at 12:03 PM Luis Gomez <ecelgp@... <mailto:ecelgp@...>> wrote: BTW below I meant "consolidate back to single distribution".
On Nov 17, 2021, at 12:01 PM, Luis Gomez via lists.opendaylight.org <http://lists.opendaylight.org> <ecelgp=gmail.com@... <mailto:ecelgp=gmail.com@...>> wrote:
I think the part that is confusing is to have 2 distros so different (life-cycle, release, tagging, etc) in the same repo, I remember we did this long time back because we wanted to avoid having a new repo for just 1 file (opendaylight/pom.xml) but since then it has been only problematic and complex (e.g. different jobs and processes for different folders in the repo).
Ideally we should separate these 2 in its own repo, jobs, etc. Or better, consolidate back to single repo if we can get TPCE to be a managed project. For your question, the only reason we need 2 distribution releases is because there is one Self Managed projects that actively participates in the ODL distribution. Also see more details on why we are releasing 2 distros here: https://docs.opendaylight.org/en/stable-phosphorus/release-process/managed-release.html <https://docs.opendaylight.org/en/stable-phosphorus/release-process/managed-release.html>, however all this managed vs self-managed release was invented in a time where we had many projects in ODL and for me this does not make sense anymore.
BR/Luis
On Nov 17, 2021, at 10:12 AM, Ha, Sangwook <sangwook.ha@... <mailto:sangwook.ha@...>> wrote:
Regarding the version mismatch for the common release, what I meant was for the karaf version in 'opendaylight/pom.xml' and the other versions - for example, release tag '14.3.0' would have the karaf version of '0.14.3' in 'opendaylight/pom.xml' but the rest has '0.14.4'. So both '14.3.0' and 'release/silicon-sr4', when released, will have '0.14.4' as the version for all the artifacts, at least when looking at the repository.
Thanks, Sangwook
On Wed, Nov 17, 2021 at 8:42 AM Sangwook Ha vialists.opendaylight.org <http://lists.opendaylight.org/><sangwook.ha=verizon.com@... <mailto:verizon.com@...>> wrote:
Looking at the release & version bump cycle, some of the steps may be simplified, and hopefully automated:
- For each release of managed projects, release & version bump, are done separately a few days apart - is there any reason why this cannot be done together? - For 'opendaylight/pom.xml' there are multiple manual steps: can steps 2 & 3 be merged & done automatically? 1) activate profiles for self-managed projects 2) release 3) update versions and deactivate profiles for self-managed projects (sometimes the version bump is done in two separate steps: the artifact/karaf & self-managed project)
And there are two different types of release tags - one for managed projects (e.g. release/silicon-sr3) and common release (14.3.0). The former does not update 'opendaylight/pom.xml' but the latter updates all the POM files. And this is confusing because all the versions except for 'opendaylight/pom.xml' have been bumped up by the time the release is made, and they have a version ahead of what the label says (e.g. for the tag '14.3.0' all the versions except for 'opendaylight/pom.xml' is '14.4.0').
Thanks, Sangwook
On Wed, Nov 17, 2021 at 1:18 AM Robert Varga <nite@... <mailto:nite@...>> wrote:
On 17/11/2021 08:26, Luis Gomez wrote: > I thought this was clear, at least to ODL old folks, the int/dist > project holds 2 distributions:
Three, actually.
> - Karaf distribution (karaf/pom.xml) only containing Managed projects is > also a Managed project and integrated with autorelease (automatic > release & bump). > - Common distribution (opendaylight/pom.xml) containing Managed and Self > Managed projects. This is a Self Managed project and therefore it has to > be manually released, bumped, etc, just like any other SM project.
Yes, and therefore the release lifecycle of int/dist is unlike any other project I have come across.
> AFAIR the sanity test you are pointing out is the only test that uses > the common distribution, all of our CSIT uses Karaf distribution. I hope > this explains.
Right-o, but unfortunately you are explaining something completely off-topic, so let me try to reiterate.
1. Ever since the dawn of autorelease MSI projects have agreed to bump the minor version, i.e. 1.2.0 -> 1.3.0
- int/dist setup was busted for almost two months - job failures have been indicating this clearly for a month - now finally everything fell apart - it was a downstream user who detected this mess
