Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Eclipse Development Process 2018
I am not sure how much we want to codify versioning semantics, it is our intention for Jetty 10 to cease all mention of Milestone or Release Candidate in versioning and communication.  This is in large part to a complete misunderstanding within the community as to what these things mean outside of OSGI users.  We have seen far too many people completely confused by 9.4.12.RC0 or 9.4.12.M0 notations and for some reason taking those to be 'higher quality' then 9.4.12.v20180830 which has been our release notation since we entered Eclipse.  We'll be going back to alpha and beta notations for Jetty 10.

I think part of the confusion comes from, again, that definition of Release vs release.  For Jetty it has always been one in the same, we have no meta roll up Release that lots of artifacts bundle up into that gets versioned differently (like versioning of artifacts in Eclipse have x.y.z.stamp, but Eclipse itself has 4.x).  Outside of osgi users our experience has been that doing the versioning we were advised to follow when entering Eclipse has been needlessly complex.  Personally, I don't understand how anyone could think that RC0 or M0 are production releases but we have seen it way more than we like.  I think the primary argument against the .v20180830 type notation is that people conflate it with maven snapshot versioning and they get scared so they use RC or M versioning.  Again, I don't understand how people come to that conclusion but the fact of the matter is they do and our plans to solve that problem in Jetty 10 is by abandoning the whole concept of RC and M release notation.

cheers,
Jesse



--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Mon, Oct 15, 2018 at 8:08 AM Nanivadekar, Nikhil <Nikhil.Nanivadekar@xxxxxx> wrote:

Project Lead: Since a Project Lead technically leads the Committers, lead should be a Committer. We should make it explicit.  What happens when a project has only 1 committer?

 

Release:

Exception 3: I feel that the release naming convention is placed incorrectly. It should be a sub-point, may be called as Release naming convention. Also, I presume milestones can be labeled as x.y-Mn or x.y.z.Mn. If they are not allowed, then we should mention that explicitly.

 

Milestones are to be labeled x.yMz, e.g., 2.3M1 (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version 2.3), etc. Release candidates are to be labeled x.yRCz, e.g., 2.3RC1 (release candidate 1 towards version 2.3). Official releases are the only downloads allowed to be labeled with x.y, e.g., 0.5, 1.0, 2.3, etc.

 

Thanks,

Nikhil.

 

 

The Goldman Sachs Group, Inc. All rights reserved.

See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it.  This message may contain confidential or privileged information.  If you are not the intended recipient, please advise us immediately and delete this message.  See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication.  If you cannot access these links, please notify us by reply message and we will send the contents to you.

 

From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> On Behalf Of Wayne Beaton
Sent: Sunday, October 14, 2018 9:24 PM
To: eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx>
Subject: [eclipse.org-architecture-council] Eclipse Development Process 2018

 

Greetings Architecture Council.

 

Please see attached the most recent version of the updates to the EDP for 2018. I've used a little diff wizardry to produce a "redline" document that shows the changes. The diff is a bit wonky in places, but I believe that it gets the point across.

 

I have a one-liner that I'm going to apply to apply pseudo-legal capitalization to the defined terms in the document (e.g. "Release Review" in all occurrences instead of "release review"). I haven't applied that yet.

 

Also, the diff had real trouble with the diagram change that I added, so diffs aren't properly highlighted on the second diagram. I will likely replace the first diagram with something that's more consistent with the way the second diagram (and the diagrams in the handbook) are rendered.

 

The source is all here.

 

I have two (fundamental) definitions that I'm struggling with. Any help that you can provide will be appreciated.

 

Project
A Project is the primary functional unit for open source development, with a dedicated team of developers that work within the bounds of a well defined Scope using infrastructure and services provided by the Eclipse Foundation.

 

Release
A Release is a specifically identifiable set of artifacts that are collectively assigned a durable tag in source control and distributed in a semantically versioned durable form of that collection intended by the developers of the project for third-party use.

 

The definition of Release in particular feels more cumbersome than it needs to be. Note that these definitions don't necessarily need to be complete: the rest of the document fills in the details. I'm really just looking for a once-sentence definition.

 

Note that the EDP itself should be agnostic of any specific technology, or notion that the EDP is specifically about "software" (e.g. specifications are not software).

 

I'm also thinking of adding "Adopter" and "User" as terms.

 

Comments welcome. Random thoughts that might spur conversation that leads to valuable changes are also welcome.

 

I intend to push out an update on Monday afternoon that includes the pseudo-legal capitalization, updated project structure diagram, and other minor tweaks after I make another pass. My hope is to push out a final draft on Wednesday.

 

Please provide any feedback or concerns as soon as possible. In order to get this in front of the Board of Directors for approval, we'll need to vote on it during our meeting at EclipseCon Europe next week. If you can't attend the conference, please let us know of any concerns

 

Thanks,


Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25



Your Personal Data: We may collect and process information about you that may be subject to data protection laws. For more information about how we use and disclose your personal data, how we protect your information, our legal basis to use your information, your rights and who you can contact, please refer to: www.gs.com/privacy-notices
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-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