[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

We had a great discussion about this at the planning council today and the we are taking action. There's still a fair amount more study to do to figure out what the fundamental issues are and come up with the right course to take. This discussion is a huge part of the input so thank you all. We'll try to do what best for Eclipse the product and brand and to reduce confusion in our community.

If you have more to add, please do so. We are monitoring this list and appreciate the help.

Doug.

On Mon, May 2, 2016 at 5:52 PM, Nick Boldt <nickboldt@xxxxxxxxx> wrote:
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
_______________________________________________
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.