Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Does Simultaneous release mean that we release on the same day

You seem to be saying opposite things there... First, that locking down a large set of software and releasing together is anachronistic, and second that "being loosey-goosey" with what gets resolved is scary. I can't figure out from that whether you are suggesting either tighter or looser coupling, or just marveling that it all works ;)

In an ideal world from a technical perspective we shouldn't have to all release together. If components have clearly defined APIs and well understood rules about how they evolved over time, then the parts should be able to move without the whole falling down. I've never seen a large software system pull that off perfectly though. Even very stable and well designed platforms like Windows and Java change over time and dependent software has to adapt. On the other hand the "one big release a year" model has other benefits, even if we didn't need to do it for technical reasons. It is easier to market/communicate to the community, and an easier model for downstream product consumers of Eclipse to plan their own schedules around.

John



Jesse McConnell <jesse.mcconnell@xxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx

05/24/2012 11:31 AM

Please respond to
"eclipse.org-planning-council"        <eclipse.org-planning-council@xxxxxxxxxxx>

To
"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
cc
Subject
Re: [eclipse.org-planning-council] Does Simultaneous release mean that we release on the same day





it makes _far_ more sense to do it that way then this all or nothing
setup that is currently the way things are done

It puts way too much pressure on all projects to have resources and
people available at a certain times to respond to potential issues.

In today's day and age the whole concept of simultaneous release is a
glaring anachronism really.  The idea of building software where you
have a 100 moving points and versions and everything is in potential
flux until some arbitrary date is the way a single company might build
their software when it is all in house, but the idea of herding a mess
of open source cats to have everything release all the same time makes
me chuckle a little bit inside.

The only reason eclipse gets away with it is because osgi lets it get
away with it, which is also the absolutely scariest aspect of osgi to
me, the whole idea of versions being loosey-goosey and a mystery shell
game that p2 lets you get away with when it starts resolving what
versions will be used when and where and by whom.

Anyway, you guys have done it this way for ages and it basically works
for you so its fine...just odd and amazing to witness.

cheers,
jesse



--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Wed, May 23, 2012 at 8:48 PM, Wayne Beaton <emo@xxxxxxxxxxx> wrote:
> In my mind, "simultaneous release" means that projects all release at the
> same time (i.e. the same day).
>
> Several projects opt to do releases in advance of the actual simultaneous
> release and basically just coast into the simultaneous release date. I find
> this a little weird.
>
> soa.bpel comes to mind as a for-instance. They did their 1.0
> release/graduation on May 2/2012.
>
> Does anybody else think that this is weird? Do I just need to get over it?
>
> Wayne
> --
> Wayne Beaton
> The Eclipse Foundation
> Twitter: @waynebeaton
> Explore Eclipse Projects
>
> _______________________________________________
> 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.
_______________________________________________
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.


Back to the top