> Create a separated branch for all the projects we select, based off
> stable/boron?
I think we need at least a separate branch based off master (Carbon),
but maybe we can add another separate branch based off stable/boron
to cover more phases at once.
In any case, we need a regular naming
for the new branch and {stream} values.
> find a leaf project
I think we also need Integration/Distribution,
just to make sure stuff like distribution-check
and CSIT jobs still work.
Of course, phased branches of distribution would
contain only minimal set of projects/features in integration.
I am not sure if Integration/Distribution is enough,
or if we need a real Java-focused offset-2 project to test with.
Vratko.
From: Alexis de Talhouët [mailto:[email protected]]
Sent: 16 August, 2016 15:50
To: Colin Dixon <[email protected]>
Cc: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
<[email protected]>; [email protected];
[email protected]; Michael Vorburger <[email protected]>
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] Fast and/or Phased
Planning for the Carbon Release
I’m willing to help as well. Do we have some kind of plan of action yet?
How about setting up and Event at the DDF [0], so we can start drawing something
in the sand, and dispatch action items.
Regardless, putting back up the straw man proposal from Colin, from which we can
iterate.
1.) pick a project to convert (odlparent? yangtools?) to publishing both
SNAPSHOT and release versions in this way
- Create a separated branch for all the projects we select, based off
stable/boron? Or do we want to tackle that on master?
I tend to think we want to do this on separate branch to avoid disruption or
whatever impact this could have.
2.) get their merge job set up (just add a second one that publishes release
versions as above)
3.) find a leaf project to consume them via the version range (so that
transitive dependencies don't screw things up)
- I think the dependencies report coming from autorelease can help pick up an
leaf project [1]
Do all the projects on which the leaf project (3) depends on has to be
converted?
If so, I suggest picking one with fewer dependencies to reduce to overhead.
4.) keep working from there
5.) make sure our release version bump scripts don't get confused, right now
they just search for SNAPSHOT and remove it
Thanks,
Alexis
[0]: https://wiki.opendaylight.org/view/Events:Carbon_Dev_Forum
[1]:
https://logs.opendaylight.org/releng/jenkins092/autorelease-project-report-boron/30/archives/dependencies.log.gz
On Aug 16, 2016, at 9:04 AM, Colin Dixon
<[email protected]<mailto:[email protected]>> wrote:
I think, yes, it would just be a set of people willing to give some time to
drive the ball forward over time.
--Colin
On Fri, Aug 12, 2016 at 7:35 AM, Vratko Polak -X (vrpolak - PANTHEON
TECHNOLOGIES at Cisco) <[email protected]<mailto:[email protected]>> wrote:
> some kind of task force
What would that be? A weekly meeting,
or just a [tag] for
[email protected]<mailto:[email protected]>
so that people can make sure they do not miss related e-mails?
Vratko (willing to help on releng and integration side of things).
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Colin Dixon
Sent: 11 August, 2016 17:25
To: Michael Vorburger <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] Fast and/or Phased
Planning for the Carbon Release
I think this thread is the best place to start trying to put together some kind
of task force and a plan for how we can build the tools we would need to move
to a fast and/or phased release process in the future. Namely, build the tools
during Carbon so that we could maybe use them as the primary part of the
release in Nitrogen or later.
The obvious candidates to help with the work would be Ed, Robert and Stephen,
but we could use help.
--Colin
On Wed, Jul 13, 2016 at 10:00 AM, Colin Dixon
<[email protected]<mailto:[email protected]>> wrote:
Right now, the way SNAPSHOTs work, my understanding is that we have a system
that is logically equivalent to semantic versioning where we fix the major,
minor, and patch versions, but bump the build version on every git commit and
then publish it. The result is that we could change our merge jobs to actually
publish that non-SNAPSHOT version to nexus and modify projects to consume the
version range:
[x.y.z,x.y.z+1)
I *think* that would wind up having the same semantics as we have today, but
have the benefits of:
1.) all published artifacts are immutable and explicitly named
2.) in theory, you could have a relatively simple local script that would let
you revert your local build to specific versions of specific artifacts
3.) projects could then decouple patches from published artifacts, say merging
4 related patches in a row and not publishing an artifact until the 4th
The obvious disadvantages are:
1.) Everyone needs to move to the version range over SNAPSHOTs at once (not
quite, but close) for a given artifact
2.) We end up producing a lot more stuff that needs to be stored in nexus
without cleaning up
Anyway, that's the straw man. The obvious way to test it would be to:
1.) pick a project to convert (odlparent? yangtools?) to publishing both
SNAPSHOT and release versions in this way
2.) get their merge job set up (just add a second one that publishes release
versions as above)
3.) find a leaf project to consume them via the version range (so that
transitive dependencies don't screw things up)
4.) keep working from there
5.) make sure our release version bump scripts don't get confused, right now
they just search for SNAPSHOT and remove it
Thoughts?
--Colin
On Tue, Jul 12, 2016 at 8:01 AM, Michael Vorburger
<[email protected]<mailto:[email protected]>> wrote:
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.
_______________________________________________
TSC mailing list
[email protected]<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
Discuss mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/discuss
