| Re: [cdt-dev] CDT 9.0/Neon M4 posted |
|
Hi Jonah,
Thank you for the follow up and nice summary. If there are no objections, for the future milestones, I suggest to use the non-composite repo in the b3aggrcon file and not update the versions. That should be the least amount of work and it will be safer than what we do right now. I think we can keep the composite repo for people who what to upgrade from miletones to milestones...or not if there is no interest. Rergards, Marc-Andre From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jonah Graham [jonah@xxxxxxxxxxxxxxxx]
Sent: Thursday, 07 January 2016 2:47 PM To: CDT General developers list. Subject: Re: [cdt-dev] CDT 9.0/Neon M4 posted (I am still getting up to speed on simrel rules and operations, debugging the plugin version in the Neon M4 release was a great way to learn all about it, but do forgive me if I have the wrong end of the stick)
From [2]:
> We could use the non-composite repo next time but we still should double check the plugin version because the CDT plugins could end up coming from other update
sites with wrong versions (projects that depend on CDT).
It seems to be a requirement going forward, not an option, that the plug-in versions are specified in a way that the M4 mixup cannot happen going forward.
I don't know if CDT specify the version in an absolute way if that completely prevents the problem of the wrong version (David Williams says the locked versions achieve 80% of the solution[3])
> [added 12/2015, for Neon] While part of the mechanics of contributing
to the build, it is required that any contribution to the Simultaneous Release repository be done by a unique change to the b3aggrcon file. There are two ways to do this. First,
your contribution repository can point to a simple repository where you know for sure there is only one version of your contribution available. Second, your contribution repository can be a composite repository but then you name exactly which versions to include.
That is you need to specify all 4 version fields. You can, of course, do both methods, simple repository and name exact versions if you want the safety of that
redundancy.
I know that Marc K recently commented "We could put the correct versions, but then at every milestone we would have to update this file, which I'd like to avoid." [5] but it seems
the bar has moved now.
On 25 December 2015 at 18:27, Marc-André Laperle
<marc-andre.laperle@xxxxxxxxxxxx> wrote:
|