[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] [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.)
[1] https://xkcd.com/1179/
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..."
$0.02,
Nick
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 <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
> https://twitter.com/brunodomedeiros_______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
>
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> 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.
http://nick.divbyzero.com
