On 20 Nov 2014, at 13:12, Leonardo Rodrigues de Mello <l...@lmello.eu.org> wrote:
> Breaking this on 4.0 is OK with semver . breaking it on 4.1 would be a mess. ACK. Question regarding package resource types using gem provider: 1. are we still able to install into system ruby using gem provider? 2. will there be an add-on to install gem add ons into puppet installation, too? > > Best > Lmello > > Em 20/11/2014 10:08, "Felix Frank" <felix.fr...@alumni.tu-berlin.de> escreveu: > On 11/20/2014 12:17 PM, Daniele Sluijters wrote: > > First question is, can you gracefully deprecate a line of agents, i.e. > > retain 3.x agent compatibility throughout 4.x masters, and drop it > > at 5.0. > > I shall assume that the engineering effort to go such a route would > > be a > > magnitude or two above just dropping cross-version support, so doing > > the > > hard cut is likely the right thing to do. But I will go on record > > stating that this is not the kind of decision that should be made > > lightly. > > > > > > But why not do it in Puppet 4 but do it in Puppet 5? This seems > > completely arbitrary like "I would prefer if you hold off to Puppet 5", > > but what's to stop it from going "I would prefer to hold off until > > Puppet 6" by the time 5 is ready to roll out? > > > > Now, that was your first question, what's the second? > > Granted, 5.0 is somewhat arbitrary. Not breaking 3.x support before the > 4.1 master would also go a long way, too, for example. > > The point is, do I need to introduce a turning point at which each of my > agents will either > a) talk to the obosolete 3.x master only or > b) talk to the newly added 4.x master only > > With a deprecation period, I can replace the 3.x master with 4.0 after > making sure that no major breakage follows suit, without the pressure of > updating each last agent (or live with two sets of potentially diverging > masters). It is only the 4.1 master that will not be viable until agents > are upgraded. > > I regard this as an advantage because such minor updates are generally > less problematic (and fear inducing to the ops team). > > The second question is the one Eric posed initially: Is a major version > change an opportune time to break the network in this fashion. The > answer to this is most definitely "yes" and - again - I'm not actively > contesting the choice to do this with 4.0. > > Cheers, > Felix > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/546DD9BB.5080901%40alumni.tu-berlin.de. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAM%3D8oN%2Bc%2BxFA%2B0W014Y7OUufEuiuxw7c2sPXQZ2aRadzf-%2BGdw%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/E1661A4A-8685-412E-A45C-AA013FE72A85%40gmail.com. For more options, visit https://groups.google.com/d/optout.
