[rudder-dev] adding feature to a technique

[François Armand]

Michael Gliwinski <Michael.Gliwinski at henderson-group.com> a écrit :

>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?

Yeah, I'm thinking about a way to separate technique development from versioning in Rudder, so that Dev could use any VCS they want with any commit convention they choose, and have an other production-compliant versioning schema alike what Jon proposed. But well, I need some more thinking !)


>
>> > 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
>*********************************************************************************
>
>_______________________________________________
>rudder-dev mailing list
>rudder-dev at lists.rudder-project.org
>http://www.rudder-project.org/mailman/listinfo/rudder-dev


-- 
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.