[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eclipse.org-planning-council] [ide-dev] Dropping the release names (Neon, Oxygen) from user downloads
- From: Nick Boldt <nickboldt@xxxxxxxxx>
- Date: Mon, 2 May 2016 17:52:52 -0400
- Delivered-to: email@example.com
I kind of like Doug's idea of having 16.0, 16.1, 16.2, and 16.3 as the
4 releases of Neon - there, the .0 is obviously the primary June
release with the .x ones following every 3 months.
But Dani's notion of date-based names that actually map to a calendar
is nice too. However, I would -100 the idea of mm/yyyy. If we're going
to do anything date-based, it has to be ISO 8601 dates for the minimum
confusion and maximum global comprehension . (Eclipse Europa was
confusing enough for those across the pond.)
Thus: Neon.0, Neon.1, Neon.2, Neon.3 ==> 2016/06, 2016/09, 2016/12, 2017/03.
>From a marketing perspective, would the absence of the simrel/release
train "fun name" make it harder to discuss & differentiate it from the
Eclipse Platform itself?
"Eclipse 16.0" might sound like the platform had simply jumped ahead a
few versions, rather than referring to the annual train. Blogs might
end up talking about "Eclipse 16, built on Eclipse 4.6..."
On Mon, May 2, 2016 at 6:11 AM, Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
> Having a baseline is important and shipping e.g. "Eclipse 2016 Update 3" in
> February 2017 would be very confusing.
> Currently we label the release with a name and a version, e.g. Neon (4.6).
> Another solution would be to keep the name and replace the version with the
> date, e.g. Neon (06/2016) and Neon.1 (09/2016) and Neon.3 (02/2017).
> From: Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx>
> To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
> Date: 29.04.2016 12:06
> Subject: Re: [ide-dev] Dropping the release names (Neon,
> Oxygen) from user downloads
> Sent by: ide-dev-bounces@xxxxxxxxxxx
> On 29 April 2016 at 09:58, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
> Gunnar, Platform may also change their policy over time so you should not
> pick a schema that assumes Platform will forever work like today
> I'm with Gunnar on this one. If the release structure/rhythm changes, we can
> always change the versioning again to better suit the new release structure.
> But not the other way around, we shouldn't change to a versioning scheme
> that doesn't suit the current release structure. Your suggestion of having a
> real date like "16.10" makes it totally unclear if it is a major release or
> a minor one.
> Bruno Medeiros
> ide-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> eclipse.org-planning-council mailing list
> IMPORTANT: Membership in this list is generated by processes internal to the
> Eclipse Foundation. To be permanently removed from this list, you must
> contact emo@xxxxxxxxxxx to request removal.
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.