Updated Release Policy
Luke Kanies
I knew our haphazard release "policy" wouldn't last once we got a few
more people doing full-time development, and it definitely hasn't.
We've been talking a bit about this informally, and I think the
following policy makes the most sense.
We have two kinds of releases: Roll-up releases, which include any
features and new bug-fixes, and bug-fix releases, which *only* fix
bugs created in the current release series.
For example, take the current 0.25 release series. 0.25.0 was a roll-
up release, including lots of features and bugfixes. When we released
0.25.1 and 0.25.2, we included fixes to bugs encountered anew in
0.25.* releases, but we also fixed bugs that existed in 0.24.* releases.
According to this new policy, that would no longer happen - bugs that
existed at 0.25.* would not get fixed until a 0.26 or equivalent
release. Or, put differently, if it wasn't worth holding up 0.25 for,
it's not worth fixing in that release series.
The goal here is to provide some kind of guarantee on increasing
release quality for a given series. If we continue fixing arbitrary
bugs at, say, an x.y.z release level, then you're just adding more
randomness to the mix.
Like any policy, this won't be cut in stone -- we can make specific
decisions to override the policy (such as the pre/post hooks we're
pushing in 0.25.4) -- but it's a rule we can hopefully use to easily
discern which tickets we should be trying to fix for a given release,
and which will, over time, make each release series more and more
stable.
Does this seem like a reasonable policy?
--
You can't have everything. Where would you put it?
-- Stephen Wright
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
Rein Henrichs
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
--
Rein Henrichs
http://reductivelabs.com
James Turnbull
Hash: SHA1
On 20/01/10 7:43 AM, Luke Kanies wrote:
> We have two kinds of releases: Roll-up releases, which include any
> features and new bug-fixes, and bug-fix releases, which *only* fix
> bugs created in the current release series.
Tentatively +1.
> For example, take the current 0.25 release series. 0.25.0 was a roll-
> up release, including lots of features and bugfixes. When we released
> 0.25.1 and 0.25.2, we included fixes to bugs encountered anew in
> 0.25.* releases, but we also fixed bugs that existed in 0.24.* releases.
Some bugs from 0.24.x - a fairly small number - also it's often hard
to identify the when of a bug.
> According to this new policy, that would no longer happen - bugs that
> existed at 0.25.* would not get fixed until a 0.26 or equivalent
> release. Or, put differently, if it wasn't worth holding up 0.25 for,
> it's not worth fixing in that release series.
Do you mean 0.24.x?
> The goal here is to provide some kind of guarantee on increasing
> release quality for a given series. If we continue fixing arbitrary
> bugs at, say, an x.y.z release level, then you're just adding more
> randomness to the mix.
Sure - would like to see this in action and not sure how many cases
of 0.24.x bugs (decreasing I think) actually get fixed, etc.
> Like any policy, this won't be cut in stone -- we can make specific
> decisions to override the policy (such as the pre/post hooks we're
> pushing in 0.25.4) -- but it's a rule we can hopefully use to easily
> discern which tickets we should be trying to fix for a given release,
> and which will, over time, make each release series more and more
> stable.
We'd bend the policy for showstoppers, security fixes, etc I
presume? What about refactors?
>
> Does this seem like a reasonable policy?
Mostly - like all our "policy" I suspect it'll need to be pretty
fluid... :)
Cheers
James
- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEVAwUBS1YfsCFa/lDkFHAyAQLqAQgAsMY1bWda3cttb22H4qgK9d0xnLrPwRou
RMVVknUw4CviELYsbFMMI/h7JUMUUmNvDN1XyTF9BR1S5HTKzlaOEL5gK4MuqMOy
AxnShOOQT8+6GuZtQWebd4nDjIc6r851y63zweAFt55Cq7YErCDs//b/WbPBJScE
xH/6+dCyD8HVwXPzEsdigtBXrnFa8caKS5gIhCsmXd+I4pZWPnv6pdg6jTcZQ53j
ZMNFswuBT4TGJVYBqUwhm1zr0sN+hIPm7nh7fVakYm5yh4VFNWg3VrNVGrBtQZtV
+QpxJt+GbNhbjUjV+7lKgI+339kXteHWZqVex5NmUAtWJntVWq+slA==
=mTxn
-----END PGP SIGNATURE-----
James Turnbull
Hash: SHA1
On 20/01/10 8:10 AM, James Turnbull wrote:
>> For example, take the current 0.25 release series. 0.25.0 was a roll-
>> up release, including lots of features and bugfixes. When we released
>> 0.25.1 and 0.25.2, we included fixes to bugs encountered anew in
>> 0.25.* releases, but we also fixed bugs that existed in 0.24.* releases.
>
> Some bugs from 0.24.x - a fairly small number - also it's often hard
> to identify the when of a bug.
And thinking about this - does this change the release cycle? We've
also not well stuck to that. If we're now only fixing older bugs,
introducing new features and? doing refactors in one release type
how often should be cut roll-up releases and bug-fix releases?
I'm obviously worried our feature release is a bit slow right now.
Regards
James
- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEVAwUBS1YhYyFa/lDkFHAyAQKAMQf+KSYa6vofwMidFl4R2n5Zx45YAqJKBUNd
Z3hCc55y2uKrGaHC50e5eDiZEDDrKNt93qT8u2ir2kIjOrnWiZz6ahu2VlyFlXGg
IEjLLMZUWsKE8AEPKzm48la/nyYfVUEezjMpxeIUHd08JCFbCzqIhvuQoO4X2x/X
UAmY1i7z27EdimV/EZ5GS4YxYvKVMwUiDrBwjwSgjV7AkjSk6PJiVxpz1Vn+sLBk
auYi2CPEIekM6+1DpeKdjcOupmapEajsZJpRPVGCeO+dquUCvpFpbpDhe3cs/FEI
u1nXh1PZ/k0JxlMLZNx888gMU+gLbBsA914+aijF3gZ4peRhOiBSZQ==
=nvCx
-----END PGP SIGNATURE-----
Luke Kanies
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20/01/10 8:10 AM, James Turnbull wrote:
>>> For example, take the current 0.25 release series. 0.25.0 was a
>>> roll-
>>> up release, including lots of features and bugfixes. When we
>>> released
>>> 0.25.1 and 0.25.2, we included fixes to bugs encountered anew in
>>> 0.25.* releases, but we also fixed bugs that existed in 0.24.*
>>> releases.
>>
>> Some bugs from 0.24.x - a fairly small number - also it's often hard
>> to identify the when of a bug.
>
> And thinking about this - does this change the release cycle? We've
> also not well stuck to that. If we're now only fixing older bugs,
> introducing new features and? doing refactors in one release type
> how often should be cut roll-up releases and bug-fix releases?
It's hard to see down the road terribly far -- the goal of this policy
is to generally produce much higher-quality bugfix releases, thus
significantly shortening their release cycle.
I'd like to stick to a quarterly feature release and come up with
another bugfix release cycle -- I'd hope for something like monthly.
This all requires some kind of consistent velocity, of course.
> I'm obviously worried our feature release is a bit slow right now.
Yeah, but this is because we've gone from Luke's slapdash style of
releasing new bugs rather than fixing old ones to Markus's "hey, let's
actually fix stuff" style. It's true that I didn't expect to miss
last quarter's feature release, but the herculean effort that Markus
and Jesse put into the tests is essentially equivalent to a feature
release.
--
Censorship, like charity, should begin at home; but, unlike charity, it
should end there. --Clare Booth Luce
Luke Kanies
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20/01/10 7:43 AM, Luke Kanies wrote:
>> We have two kinds of releases: Roll-up releases, which include any
>> features and new bug-fixes, and bug-fix releases, which *only* fix
>> bugs created in the current release series.
>
> Tentatively +1.
>
>> For example, take the current 0.25 release series. 0.25.0 was a
>> roll-
>> up release, including lots of features and bugfixes. When we
>> released
>> 0.25.1 and 0.25.2, we included fixes to bugs encountered anew in
>> 0.25.* releases, but we also fixed bugs that existed in 0.24.*
>> releases.
>
> Some bugs from 0.24.x - a fairly small number - also it's often hard
> to identify the when of a bug.
In many ways it's not the specific number that matters but the
mentality. Each x.y.z release should be as small as is reasonable,
rather than as complete as possible.
>> According to this new policy, that would no longer happen - bugs that
>> existed at 0.25.* would not get fixed until a 0.26 or equivalent
>> release. Or, put differently, if it wasn't worth holding up 0.25
>> for,
>> it's not worth fixing in that release series.
>
> Do you mean 0.24.x?
Probably. I think I actually meant something like 'at release of
0.25.0', but eh.
>> The goal here is to provide some kind of guarantee on increasing
>> release quality for a given series. If we continue fixing arbitrary
>> bugs at, say, an x.y.z release level, then you're just adding more
>> randomness to the mix.
>
> Sure - would like to see this in action and not sure how many cases
> of 0.24.x bugs (decreasing I think) actually get fixed, etc.
There are a ton of bugs that are floating out there that we'd like to
fix, and it's mentally exhausting assessing them for *every* release.
The big difference here is you have a very simple operation for the
x.y.z releases - "which bugs have we caused in this release series?".
When you put out x.y.0 releases, you have a much more complex release
cycle, but you have longer to do it and you expect to go through a
couple of iterations (although, of course, we hope those go down in
count, too).
>> Like any policy, this won't be cut in stone -- we can make specific
>> decisions to override the policy (such as the pre/post hooks we're
>> pushing in 0.25.4) -- but it's a rule we can hopefully use to easily
>> discern which tickets we should be trying to fix for a given release,
>> and which will, over time, make each release series more and more
>> stable.
>
> We'd bend the policy for showstoppers, security fixes, etc I
> presume? What about refactors?
Unless it's refactoring that resulted from work done in that release
series, it should generally get delayed.
>> Does this seem like a reasonable policy?
>
> Mostly - like all our "policy" I suspect it'll need to be pretty
> fluid... :)
Indeed.
--
If you're not part of the solution, you're part of the precipitate.
-- Henry J. Tillman