[rudder-dev] adding feature to a technique

[Nicolas Charles]

On 03/02/2013 13:56, Jonathan Clarke wrote:
> On 03/02/13 13:14, Michael Gliwinski wrote:
>> Hi all,
>
> Hi Michael,
>
>> 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?
>
> 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.
>
> 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:
>
>   * Minor version increments should be for bug fixes (ie, in the
>     example above, a bug in 1.1 would be fixed in 1.2)
>   * 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.
>   * 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.
>       o 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.
>       o This also means that minor versions could not introduce new
>         variables (or change constraints on existing variables).
>
> What do you think about this versioning policy, everyone?
>

I feel there are three missing elements in this policy :
- "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"
- 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
- 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.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20130213/18b6ceb0/attachment.html>