[RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> Hello,
> 
> Today I've upgraded one of my personal FreeBSD servers. It's running
> FreeBSD 11.0 for a while.
> 
> While I use quarterly ports branches, I usually update my ports tree
> before installing a new service and I faced some troubles:
> 
> www/node was updated from 6.x to 7.x: unfortunately my etherpad
> instance is not compatible with 7.x. I needed to install www/node6.
> 
> devel/mercurial was updated to 4.2: redmine has a small issue making
> repository browsing unavailable. I temporarily downgraded Mercurial to
> 4.0.
> 
> I think the current process of having rolling-releases packages makes
> unpredictable upgrades as we have to manually check if the upgrade
> will be fine or not. When a user installs FreeBSD 11.0 on its system,
> it probably expects that everything will work fine until a next major
> upgrade like 12.0. That's why I think we really should implement
> branches for a specific FreeBSD version.
> 
> When FreeBSD 12.0 is released, we should create a ports branch that
> will contains only fixes (such as security advisories, crash fixes and
> such). No minor or major upgrades until a new 13.0 version is
> released. This is the only way to make safe upgrades.
> 
> If user think that a software is too old (since we have long delay
> between major releases) it can still use the default tree at its own
> risks.
> 
> Additional benefits of having a ports tree by version: you don't need
> to have conditionals in ports Makefiles (how many ports check for
> FreeBSD version? a lot).
> 
> Any comments are appreciated.

As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

What do you do for security fixes: backport to the stable version? who is
backporting to software not maintained upstream any more in the given branch?

Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20170622/1fdeecf2/attachment.sig>