On Mon, Dec 5, 2016 at 3:01 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
> There is another problem with .0...N releases. As soon as you version
> your main release like that, everyone assumes .0 is unstable or broken
> and they wait for .1. Some wait for .2 (which doesn't exist in your
> proposal but clearly could). This is a perception problem more than
> anything, but it exists and is quite common. In products that have a
> multi-year lifespan that isn't ideal but it also isn't the end of the
> world. It just means your adoption curves look similar to Fedora's
> today and the end result is that the majority of your users are
> migrated when that release is well into its support lifecycle.
>
> In a Fedora world, it means your .0 release gains limited adoption,
> with .1 being more popular (OK so far), but then M.0 comes out in 6mo
> and you reset. Essentially you've adjusted your adoption rate to
> spike on the .1 updates, and artificially limited the userbase of that
> major release. That in turn limits the testing and deployment
> opportunities which limits the fixes you can get into .1 to make it
> better. I'm not sure that's a net win.
I think that's become somewhat quaint in practice, as most people have
been opting in to Apple's annual macOS updates within a month of
release for some time now. The same is effectively true on Windows 10
(aside from the more compulsory/trickery aspect). There's a deemphasis
on the fact it's a .0 release also. It's X number without a .0, and
only gets .1, .2 and so on.
>
>> Rawhide is a good question. I'd like to see the more-stable-rawhide
>> ("Bikeshed!") idea in place, and hopefully more people running that,
>> making it more likely that Rawhide is at a good place for stabilization
>> when we branch for the annual release.
>
> The simple answer there is that Rawhide becomes your (gated) rolling
> release, and the releases deviate from it by stability and lifecycle.
> This is essentially what SuSE has done with Tumbleweed and Leap,
> respectively.
Although Leap is based off SLE rather than Tumbleweed, older kernels
and such, plus some more stable newer things from Tumbleweed.
--
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
