Hello,
On Thu, 26 Jan 2012, Da Rock wrote:
I normally hate to dredge up old threads, but this is like getting halfway
through a story and not finding out the ending... :)
What is the answer? Is there a solution to this?
When I wrote the original post, I was expecting at most a benign response,
and at worst some real blowback ... but I was really pleasantly surprised
to find that my complaints were very well received, and that a lot of
folks were experiencing the same issues that I was.
It appears to be a classic case of "if one customer complains, 99 others
are thinking the same thing".
I have a string of questions on this:
1. Incidentally, what exactly does constitute a major release?
I was defining major releases to be 4.x, 5.x, 6.x ... and so on.
Currently 9.x is the latest major release.
2. Is there a reason to update the numbers so quickly?
I didn't think so, which was one of the main points of my post. A lot of
other folks have agreed. BUT there were some counter arguments -
specifically that fully new features would be delayed for a much longer
time AND that there would be large architectural gulfs between major
releases.
For instance, we might have waited an extra 3-5 years for any ZFS support
at all in a -RELEASE, and when it appeared, it would introduce a big
upgrade hurdle, as it would be accompanied by major underlying changes in
system architecture.
But my counter to this was that a lot of these features that we did get
introduced to, earlier, were in fact not really usable anyway. For
instance, my firm(s) have not even considered production use of ZFS until
8.3-RELEASE.
So the question remains, where do we set that dial ?
If it were up to me, I think I would stake out a very loud and clear
mission statement for FreeBSD that explicitly sacrifices new features for
longer lifecycles and deeper investment in particular releases. I've
thought seriously about the points that were made in this thread
supporting faster releases, and I do appreciate what we would be giving
up, but I continue to advocate for a new major release every 5 years.
I don't think that's going to happen, but based on this discussion and
feedback, it appears that we're going to get more frequent minor releases
- possibly 3-4 per year - which makes me very happy.
3. Could a higher bar be set to reach a major release than simply temporal
objectives? One of the differentiating factors between linux and FreeBSD is
the simple fact that linux distros tend to run so fast through the numbers-
and while just a matter of perspective, it could provide some sense of
stability to enterprise users. Weighed against, of course, the ability to
upgrade easily.
I think temporal objectives are decent, provided they are long :) Long
timelines give people and organizations incentive to invest time and money
into a thing. I know very well of several investments in FreeBSD that my
firm(s) did NOT make because we didn't think it was worth it, given that
the release, and underlying arch, were going away.
4. If in the case of the former, could some backporting to the stable and
release branches facilitate an easy upgrade to the next major release?
5. Could binaries be the answer to easier upgrades (customised for enterprise
users)?
I think others have had better comments and insight as far as those two
points are concerned.
I think you would be well served to read the entire comment thread, and
just ignore all of the posts that are speaking about PRs - they were
off-topic almost immediately and devolved from there.
A good tl;dr is from a post I made early on:
<quote>
You could progress 8.x along its current trajectory, possibly building 8.4
a year or so from now and then be done with it, and then that would be the
last short/unfocused release.
Then you postpone 10.0-RELEASE until January 2017.
Instead of having a legacy branch and two production branches, you would
have legacy (8) production (9) and ... nothing. Or if you need to have it
out there, 10 is the development branch.
Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
at the end of the cycle.
</quote>
Again, I don't think this is how it will pan out, but it was my favorite
scenario. I'd be very happy and satisfied if we just got:
a) more frequent (3-4) minor releases
b) just one version declared as "production" at any given time[1]
And I'd be pretty happy if we just got (a), which I think we will.
--john
[1] There were a lot of "me too" posts about more frequent minor releases,
and the short lifecycle of major releases, but I was surprised that nobody
else was bothered by the existence of two simultaneous "production"
releases. To me it seems obviously distracting and confusing - and
results in new revisions of drivers, etc., skipping the earlier
"production" release.
No matter where we decide to set the lifecycle dial for major releases, I
really think we should rename the later one "development" ...
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
