[rudder-dev] adding feature to a technique

Michael Gliwinski Michael.Gliwinski at henderson-group.com
Sun Feb 3 16:40:09 CET 2013


On Sunday 03 Feb 2013 13:56:14 Jonathan Clarke wrote:
> On 03/02/13 13:14, Michael Gliwinski wrote:
...
> > 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?

This makes perfect sense.  The only drawback I can see is that finding history 
of changes to a file (from vcs) will become more difficult because pretty much 
before starting development you'll be creating a copy.

Unless the versioning could be somehow separated from the source?

> > I've a small addition to fileManagement, to allow maintaining local
> > copies of files (needed that in some cases where dropping a symlink
> > wouldn't work for security reasons, e.g. cron.d files).
> > 
> > So far I patched version 1.0 which works OK for me, but I wanted to
> > submit it> 
> > :)
> 
> Sounds great! I must buy you a beer ;-)

Haha, so far I owe all of you a round for releasing Rudder!
Too bad we didn't get to meet yesterday, but maybe next year :)


**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It is intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed  in the governing client engagement leter or contract.
If you have received this email in error please notify support at henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************



More information about the rudder-dev mailing list