Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] About features documentation changes in Indigo Service Release 1

I'm not sure it's entirely up to each project to decide what they put in a service release. The Eclipse dev process [1] says that maintenance releases must have no "no new features". I guess the definition of a feature is subjective but it does imply a fairly limited scope. If you introduce new functionality then it's not a maintenance release and it requires a full Release Review, approved IP log, etc. Having said that, I'm not sure if the planning council ever decided that release train Service Releases contain only maintenance releases from its participating projects. Could an individual project on the train decide to do a major new release, conduct a release review, and then contribute that major release to Indigo SR1? Maybe this is a potential topic for the next call if it hasn't already been covered before.

John



[1] http://www.eclipse.org/projects/dev_process/development_process_2010.php#6_4_Releases



David M Williams <david_williams@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

07/25/2011 10:04 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] About features documentation changes        in        Indigo Service Release 1





It sounds like your proposed changes would be fine ... but, I'll give a long answer too.

There's no strictly imposed limit of what goes into a Service Release ... it really up to the project to decide. But ... we can always provide some advise ... :)


The most important rule is it should not be anything that breaks adopters or users or other Eclipse projects or the overall aggregation process. I think the reason it is worded that way, "... fixes to a small number of serious problems" is an attempt to say "keep the risk of breakage low, and make sure any benefits is well worth the risk".


Another guideline, if any change is large enough to normally require a change in 'minor' versioning field, not just 'service' field, then that sort of "large change" should be well communicated here on cross-project list (with reference to bugzilla entry). It is possible that the mere change in a 'minor' field might "break" an adopter depending on how they have defined their prereq versioning ranges, so it is discouraged to make such a large change in maintenance. But, in some circumstances, some projects have found it necessary, and in some circumstances, the risk of  breakage is pretty low ... depending on what it is, and where it is at in the food chain, etc. And, maybe everyone would agree it would be worth the risk.


Another, more philosophical point, is that some believe faster and larger overall progress can be made, in software development in general, by minimizing maintenance fixes to only what really _has_ to be done, and focusing more on the next release.


But, there's not one rule that fits all cases ... some projects may have good reason or business needs to include a larger number of changes that are not all to fix "serious problems", so that's why it is primarily up to each project, and all we ask is you keep everyone well informed if new features added, or changes to "minor" version levels are made.


While it doesn't sound like it'd apply to these proposed documentation improvements, some projects have found it necessary to have an "off cycle" release on their own schedule, available from their own project repository, that would independent of Indigo Maintenance but instead some early version subset of what would eventually be included in Juno. That way, it reduces risk for "casual" consumers of maintenance, while some users or adopters can get the latest version if they need it and if they can absorb the changes.


That's all probably more than you were really asking, but hope it helps you decide how to proceed, and I hope also others that may have similar questions. Please ask again, if its not clear, or if you (or others) want to give more details.


Thanks for asking,







From:        
fgiquel@xxxxxxxxxxxxxxxx
To:        
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        
07/25/2011 05:01 AM
Subject:        
[cross-project-issues-dev] About features documentation changes in        Indigo Service Release 1
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




Hi all,


about the content of changes delivered into Indigo SR1,  Helio SR1 end game page (did not found the Indigo SR1 one) indicates that "maintenance release contains fixes to a small number of serious problems".


Are there limitations about the nature of "fixes" to the features documentation (help content) ? I mean, some mistake or lack in documentation cannot be considered as a "serious problem" but cannot represent a risk regarding to Indigo SR1 safety.


Moreover, is there any limitation to use SR1 end game to make evolution to our documentation generation releng tooling, or is it recommended to wait to Juno for such releng process evolution ?


Thanks in advance.


---------------------------------------------------------------
Fabien GIQUEL
Responsable Développements Nouvelles Technologies
fgiquel@xxxxxxxxxxxxxxxx
Mia-Software
4, rue du Château de l'Eraudiere
44324 NANTES CEDEX 03
---------------------------------------------------------------
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top