Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] [ide-dev] Dropping the release names (Neon, Oxygen) from user downloads

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 [1]. (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:
> +1
> 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).
> Dani
> From:        Bruno Medeiros <>
> 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
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> _______________________________________________
> 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.

Back to the top