Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Postmortem Release Path



On Fri, Jun 1, 2018 at 4:29 PM, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:

To be precise and in keeping with your analogy, I don't want to ever get on a plane that was allowed into the air without a pre-flight check since statistics suggest in that case a Postmortem Review would be exactly what happens next! ;-) I might argue that the same is true with the software I use. My question therefore breaks down to:

Sure, but while a pre-flight check is useful I think the mechanics (developers) are best equipped to do it and if it lands then no one need care about the nuts and bolts, but if there was an issue then the FAA needs to get involved and help figure out what part of the process broke and let the engine fan crack be missed.

 

* What does this give us that is functionally better than the current process?


Right now there is very clouded definition of what a 'release' is.  I generally try and explain it as a big R-elease which is I see as the traditional Eclipse release (for Jetty: 9.x -> 9.y, 9 -> 10), goes through the process of creating docuware, scheduling release reviews, etc etc.  Then there is the vast majority of little r-eleases that a project like Jetty does which are incremental releases on a minor version (9.4.x -> 9.4.y) which I think most closely resembles what I think Wayne calls a Service Release.  These are supposed to just be fixing bugs and perhaps in the world of OSGI that makes sense but it is a poor definition for a project like Jetty.  I think OSGI views a service release as 9.4.1.v20180101 -> 9.4.1.v20180202 which would make our users heads pop, we are dropping the v201080202 portion of our versioning for Jetty 10 because of the massive confusion within the community (we have had way too many people use M0 or RC0 releases because the v2018xx versions scared them into thinking they were snapshots and not official).

Anyway, Wayne said one thing that bothered me on the last call when he specifically called out these service releases as not requiring a formal release review.  He said that they needed to be bugfixs only, specifically calling out not adding functionality.  Careful review of Jetty point releases will show what we add apis as needed to expose what we consider improvements or functionality but that do not alter negatively what we consider our external api. To do otherwise would completely stall the project and halt any sort of incremental innovation we strive for.  So we see the definition of 'Functionality' as different for Eclipse then for us and our users, the difference being one of granluarity.  As an example, we see adding another session manager (like memcache) as a funtionality for Jetty, but not by Eclipse's definition.  For Eclipse, I see replacing the entire session management implementation as a new Feature (which was something that prompted 9.3->9.4 for Jetty) since it would involve dramatic API changes.

I think this once again goes back to the poor definitions that I see floating around the Eclipse processes when I try and wedge non-osgi development practices like Jetty into it conceptually.  I believe acknowledging this was the reason someone like me was was invited to this august body. :)
 

I don't think the definition of a "service release" is poor or related to OSGi. See the Eclipse projects handbook, which in general is a good read:

> A service release is defined as a release that is backwards compatible and contains only bug fixes.

So that statement doesn't make any assumptions about version numbers. I would say all that you where saying is already covered in the current process.

But maybe it needs to be communicated in a better way. And I do agree that when you talk to people with a heavy background in OSGi, you might get a wrong impression ;-)



Back to the top