<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 03/02/2013 13:56, Jonathan Clarke wrote:
<blockquote cite="mid:510E5E6E.1040009@normation.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 03/02/13 13:14, Michael Gliwinski
wrote:<br>
</div>
<blockquote cite="mid:1416902.FoRh5zY5yp@hgis96" type="cite">
<pre wrap="">Hi all,</pre>
</blockquote>
<br>
Hi Michael,<br>
<br>
<blockquote cite="mid:1416902.FoRh5zY5yp@hgis96" type="cite">
<pre wrap="">Just a quick question about the process for adding features to a technique.
How do you decide if a new version (major/minor) of a technique should be
created for a feature?</pre>
</blockquote>
<br>
This is currently a bit of blurred definition. Until now, we have
always said that bug fixes in Techniques should be applied to all
versions, with no version increment (ie, if a bug is in version
1.1, we fix it in 1.1, without incrementing it). This is not a
great approach IMO, since versioned software/code/whatever should
never change. The reason we did it this way was to make sure that
Rudder users got bug fixes as soon as they are available.<br>
<br>
In the future, I would like to move to a clearer versioning
policy. This remains to be discussed, and hopefully this email can
be a start to the discussion, but here's what I was thinking:<br>
<ul>
<li>Minor version increments should be for bug fixes (ie, in the
example above, a bug in 1.1 would be fixed in 1.2)</li>
<li>New features would require a major version increment. So, a
new feature in a Technique in version 1.1 would be implemented
in 2.0.</li>
<li>By default, Rudder would automatically use the latest minor
version given a major version. So if I'm using a Technique in
version 1.*, currently 1.1, and 1.2 is available, Directives
are automatically upgraded to 1.2.</li>
<ul>
<li>This behaviour should be disable-able on a per Directive
basis, and on a global basis, to enable "freezes" such as
exist in many companies.<br>
</li>
<li>This also means that minor versions could not introduce
new variables (or change constraints on existing variables).<br>
</li>
</ul>
</ul>
What do you think about this versioning policy, everyone?<br>
<br>
</blockquote>
<br>
I feel there are three missing elements in this policy :<br>
- "Size" of upgrade. Some modifications in techniques are a simple
feature added (filePermission 1.1), some others are complete
refactoring without any change for the user (sshConfiguration 2.0),
and some are complete change (copyGitFile 1.1); the versionning
policy should reflect this, like "I need to fill one more field,
it's easy", "I don't need to change anything, it's straightforward",
"i'll have to change everything, oh no"<br>
- Deprecation. Some Technique may be marked as deprecated, when
newer version fits more clearly the need. Having too many versions
may be confusing on which version to use<br>
- Change. There is nothing (yet) that explains the differences
between each version of a Technique, one need to look at the GIT
history to know what is new.<br>
<br>
Nicolas<br>
</body>
</html>