Upcoming release schedule - 8.4 ?

[Rick Macklem]

Mark Saad wrote:
> I'll share my 2 cents here, as someone who maintains a decent sided
> FreeBSD install.
> 
> 1. FreeBSD needs to make end users more comfortable with using a
> Dot-Ohh release; and at the time of the dot-ohh release
> a timeline for the next point releases should be made. *
> 
> 2. Having three supported releases is showing issues , and brings up
> the point of why was 9.0 not released as 8.3 ? **
> 
> 3. The end users appear to want less releases, and for them to be
> supported longer .
> 
> * A rough outline would do and it should be on the main release page
> http://www.freebsd.org/releases/
> 
> ** Yes I understand that 9.0 had tons of new features that were added
> and its not exactly a point release upgrade from 8.2 , however one can
> argue that if it were there would be less yelling about when version X
> is going to be EOL'd and when will version Y be released.
> 
One thought here might be to revisit the "Kernel APIs can only change on
a major release" rule. It seems to me that some KPIs could be "frozen"
for longer periods than others, maybe?
For example:
- If device driver KPIs were frozen for a longer period of time, there
  wouldn't be the challenge of backporting drivers for newer hardware to
  the older systems.
vs
- The VFS/VOP interface. As far as I know, there are currently 2 out of
  source tree file systems (OpenAFS and FUSE) and there are FreeBSD
  committers involved in both of these. As such, making a VFS change within
  a minor release cycle might not be a big problem, so long as all the
  file systems in the source tree are fixed and the maintainers for the
  above 2 file systems were aware of the change and when they needed to
  release a patch/rebuild their module.
- Similarily, are there any out of source tree network stacks?

It seems that this rule is where the controversy of major vs minor release
changes comes in?

Just a thought, rick

> 
> 
> --
> mark saad | nonesuch at longcount.org
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at freebsd.org"