1 |
On Thu, 09 Mar 2017 16:34:20 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> 1. classic forks -- package B is forked out of A, and the development of |
5 |
> both continue independently (eudev/systemd, ffmpeg/libav); |
6 |
> |
7 |
> 2. large patch sets / continuously rebased forks -- where the particular |
8 |
> set of changes is usually applied to mainline or regularly rebased |
9 |
> against mainline but without full separation (kernel patchsets, bitcoin |
10 |
> patches); |
11 |
> |
12 |
> 3. abandoned package forks -- package A stops being maintained upstream, |
13 |
> someone forks it and starts working on top of that (xarchiver). |
14 |
|
15 |
I think any formal guideline needs to be clear that these statements are with regards |
16 |
to *mutually exclusive* forks, where dual-installation is not viable and/or auto-linking |
17 |
magic would do bad things if they were co-installed. |
18 |
|
19 |
Partly because not all forks are done by 3rd parties. Some projects "Self fork". |
20 |
|
21 |
But here, the distinction between "fork" and "major version" blurs, because often |
22 |
the reason for a "self fork" is to explicitly allow cohabitation with the "old fork", |
23 |
in a manner very akin to "new major version in new slot". |
24 |
|
25 |
So with that said, in all of those cases, if the "new" fork and the "old" fork don't |
26 |
directly compete at a physical level, even though they share logical ancestry, they can be considered |
27 |
new independent software. |