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 believe that there is precedent for adding functionality in a service release.

As John states, a EDP release review is generally required.

Wayne

On 07/25/2011 01:14 PM, John Arthorne wrote:
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


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

-- 
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton

Back to the top