[rudder-dev] adding feature to a technique
Jonathan Clarke
jonathan.clarke at normation.com
Sun Feb 3 13:56:14 CET 2013
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'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 ;-)
So for this particular case, I would suggest submitting a new major
version, because this is quite a significant improvement, and would fit
with this new versioning policy if we adopt it. To submit, the preffered
approach is to use a GitHub Pull Request.
Jonathan
--
------------------------------------------------------------------------
*Jonathan CLARKE*
/CTO - Directeur technique/
Normation <http://www.normation.com>
------------------------------------------------------------------------
*87 rue de Turbigo, 75003 Paris, France*
Telephone: +33 (0)1 83 62 41 24
Mobile: +33 (0)6 99 60 03 10
------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20130203/7daacc40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-square.png
Type: image/png
Size: 3503 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20130203/7daacc40/attachment.png>
More information about the rudder-dev
mailing list