Just wondering here... but since LTS has the a goal of having a set of set points in time (the existing releases) that is maintained into the future, doesn't it make sense to have LTS be the primary stakeholder for the entire simultaneous release concept (maybe they are?)
and then if, as Doug is calling for here, there was interest in a more fast moving, ideally generally bug free but sometimes glitchy IDE experience then folks can download and update their editor based on that stream? And have a durable update repository that isn't getting smoked, renamed, or what have you that people can just use for years on end. A bit like how ubuntu lets you have your stable and unstable streams that you can keep updated from As for version resolution...I thought one of the points of osgi was to allow multiple runtime versions of stuff to coexist so from a repository perspective, let them update whatever they want and downstream projects that trust their upstreams can have open version ranges and those that don't can take a more deliberate approach. I am aware I am probably trivializing much of the osgi experience there, but really...from a users perspective of Eclipse (which I am speaking from) I would like to just be able to flip a switch in the IDE and have it notify me of updates, download in the background and either update automagically or restart the IDE as needed and not care about adding p2 update repo this for that thing or download Milestone X or Y or whatever... cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jul 3, 2013 at 11:53 AM, Mike Milinkovich < mike.milinkov...@eclipse.org> wrote: > > > On the flip side, we need to evaluate the benefits of more frequent > releases to > > see if it's worth it. > > Completely agree. My assumption is that some projects will want to ship > more > often, and some will not. We have a large community, and one size rarely > fits all. A strategy that can accommodate differing requirements will be > necessary. > > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
