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). Scott On 18-12-12 03:17 PM, Khalil, Ghada wrote:

Scott was going to put the final release version (19.05) a little closer to milestone-3 / RC1. Do you prefer to have it set from now?

Ghada

-----Original Message----- From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Wednesday, December 12, 2018 3:11 PM To: Little, Scott; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] changing PLATFORM_RELEASE

This makes sense to me. Should we set the value to the next planned release date?

brucej

-----Original Message----- From: Scott Little [mailto:scott.little@windriver.com] Sent: Wednesday, December 12, 2018 11:41 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] changing PLATFORM_RELEASE

Or master branch builds are still reporting PLATFORM_RELEASE=18.10. This value is also known as the SW_VERSION.

To avoid confusion, I propose the following.  After we cut a release branch, should always advance the master branch value by at least +1 month beyond that release, but never greater than -1 month to the next projected release date.

I propose changing the current master branch to PLATFORM_RELEASE=19.01

Scott

_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss

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@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