13.1 from main?

[Ronald Klop]

Hi,

Just wondering a bit. Why wouldn't the FreeBSD project release 13.1 from the main branch in about six months or some other time period? While making some monthly errata releases in the meantime.
- This saves a lot of back porting of commits.
- It prevents branches with old code like the current 11-branch with an old openssl version. Release early.
- Saves some people time in maintaining the branches.
- Saves time in coordinating the releases. Release often.
- Reduces the number of needed RC's. Because the main branch doesn't divert a lot of what people are running in production.
- Most people start testing/production use after the release. So this should be used as input for the main branch to improve the next release. Currently the feedback of 13.0 is put in 14.0 which is 2 years in the future.

Just some thoughts. Which I really like. :-)

Regards,
Ronald.

[Alan Somers]

Because we have a policy of never releasing anything even a little bit
backwards-incompatible in a minor release. imp, for example, has been
removing obsolete drivers in main. We can remove old drives in a major
release, but not in a minor one. That's why we can't release 13.1 from the
main branch.
-Alan

Post by Ronald Klop
Hi,
Just wondering a bit. Why wouldn't the FreeBSD project release 13.1 from
the main branch in about six months or some other time period? While making
some monthly errata releases in the meantime.
- This saves a lot of back porting of commits.
- It prevents branches with old code like the current 11-branch with an
old openssl version. Release early.
- Saves some people time in maintaining the branches.
- Saves time in coordinating the releases. Release often.
- Reduces the number of needed RC's. Because the main branch doesn't
divert a lot of what people are running in production.
- Most people start testing/production use after the release. So this
should be used as input for the main branch to improve the next release.
Currently the feedback of 13.0 is put in 14.0 which is 2 years in the
future.
Just some thoughts. Which I really like. :-)
Regards,
Ronald.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Steve Wills]

Hi,

Post by Alan Somers
Because we have a policy of never releasing anything even a little bit
backwards-incompatible in a minor release.

I believe we have made backwards incompatible changes in minor branches
in the fairly recent past, at least compiler changes and VM changes that
affected video drivers. But I'm not sure, please correct me if I'm wrong.

Cheers,

Steve

[Warner Losh]

Post by Steve Wills
Hi,

Post by Alan Somers
Because we have a policy of never releasing anything even a little bit
backwards-incompatible in a minor release.

I believe we have made backwards incompatible changes in minor branches
in the fairly recent past, at least compiler changes and VM changes that
affected video drivers. But I'm not sure, please correct me if I'm wrong.

Userland guarantees are easier to achieve than private kernel interfaces.

Compilers have been binary compatible always, though newer versions were
pickier at times which caused some minor grief (though that had nothing to
do with the video driver stuff).

By and large, things are broadly compatible. in the minor releases. And
that's a good thing since we need packages for fewer release trains. But it
also means things can take longer to get into a release. It's a balancing
act, really, that we set the balance for decades ago and we may benefit
from a close re-examination to see if a different model would let us use
resources better and/or deliver features more quickly.

Warner