| Re: [eclipse.org-planning-council] SimRel Naming |
|
Gunnar, Comments below. On 04.05.2018 10:43, Gunnar Wagenknecht
wrote:
Assuming we did coordinate such things, there would be just one. :-P But that's up in the air. I think at this point there is no actual point of confusion. If that's what they want. They might want to call it the Eclipse Jakarta Train. Who knows what they'll want to call that. But note that we have enough trouble herding all the cats involved in the current process, so adding several new herds of cats isn't going to make that any easier, especially when we need to name/brand each heard, and try not to overwhelm each herd with details that might well not be significant to all herds. E.g., we just cross-projects a lot, but clearly that's grown to be a herd of herds. :-( Exactly. Well, certainly not named and branded to be exclusive of them, yes. People out there build interesting runtime applications from things like EMF and CDO and they can get all coordinated versions of all this into their target platform from the train URL. Yes, of course that's the main understanding, but in actual fact the train URL is a good place to pick up a broad range of dependencies when building applications. That's why I'd rather avoid the whole mess and see what comes out in the wash. Exactly, always the sigh at the end. :-( Yes, I'd really like to see such a list of "here are the places we need a name". E.g., we needed URLs in in the wiki sooner rather than later... A segment in a URL is not a brand. :P It's clear from Board discussions that URLs are not part of the discussion about naming and branding. That doesn't mean we want crappy ones of course! The names of Eclipse Projects (and of the Eclipse Project, sigh), is also not part of this Planning Council discussion. I've seen several proposals so far. But now we start getting into really technical details about which repos are composites and which are simple and what will be the URL for the new simple repo that's produced 4 times each year? Note that we already have http://download.eclipse.org/releases/latest That's a composite with a single child that should always reference the simple repository with the latest release (in my opinion). The next release could a simple repository in http://download.eclipse.org/releases/2018-09 Or perhaps in http://download.eclipse.org/releases/simrel/2018-09 But what the simrel buys us I'm not sure? And again, a URL is not a brand. No. Somewhere there needs to be a new simple repo 4 times each year. And please for goodness sake let's not create giant growing composites that are pretty much worse than useless because the serve mostly the kill download.eclipse.org by forcing it to serve up metadata for older stuff that's never actually installed or resolved. No, that should only ever contain the one release we produce in June! The simplest most obvious thing to me would be to produce a new http://download.eclipse.org/releases/YYYY-MM 4 times each year and make http://download.eclipse.org/releases/latest point at it. Perhaps have http://download.eclipse.org/releases/milestones to reference the most recent milestone simple repositories. And perhaps http://download.eclipse.org/releases/milestomes/latest as a composite to reference the most recent milestone simple repository. Clearly the Planning Council does need a plan for where the URLs would be, with thought toward such horrible events as shipping a release with a major bug that needs remediation before the next quarterly release...
|