[Starlingx-discuss] changing PLATFORM_RELEASE
Scott Little
scott.little at windriver.com
Wed Dec 12 21:25:38 UTC 2018
I like the idea of the milestones using a date that match the interim
PLATFORM_RELEASE value.
I'd like to avoid deviating from the YY.MM format of PLATFORM_RELEASE
anytime soon. I think there is a fair bit of infrastructure, including
our internal test automation, that would be sensitive to such a change.
On 18-12-12 04:03 PM, Dean Troyer wrote:
> On Wed, Dec 12, 2018 at 2:31 PM Scott Little <scott.little at windriver.com> wrote:
>> Until we are at least RC quality, we shouldn't set PLATFORM_RELEASE to
>> the final date.
>>
>> Also keep in mind that this value should never go backwards. So I want
>> to leave some wiggle room, just in case (however unlikely) we move the
>> release date forward (perhaps 19.03).
> This is essentially the same problem Scott and I have been talking
> about re naming the milestones.
>
> The downside to using date-based release names is when the value of
> $NEXT_RELEASE is unknown it is hard to use it in places like milestone
> names.
>
> Would it be too confusing to just use values as of the date we need
> the value, ie milestone 1 is based on 2018.01 no matter when the
> release actually occurs? Would this be too confusing to
> users/deployers/developers?
>
> So we would have this:
> milestone 1 in Jan 2019:
> tag=2019.01.b1
> PLATFORM_RELEASE=19.01 or 19.01.b1 or similar
>
> milestone 2 in Mar 2019:
> tag=2019.01.b2 or 2019.03.b1
> PLATFORM_RELEASE=19.01 or 19.01.b2 or similar
>
> dt
>
More information about the Starlingx-discuss
mailing list