There's been an update to the gkrellm mailing list about progress on the
gtk3 conversion.  It seems much of the work is being done in a specific
git branch.  If I want to create an ebuild to track that branch instead
of master, what would be an appropriate numbering of that ebuild?  Just
using a different name with 9999 would work - but then those two names
would have to block each other, since I don't think they could
co-exist.  Are there any examples I can look at?  Just adding something
after the 9999 doesn't seem right, nor does something like 9998.

Any thoughts or suggestions?

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ionen,

Thanks for the feedback.

On 2024.11.16 17:33, Ionen Wolkens wrote:

On Sat, Nov 16, 2024 at 05:04:43PM -0500, Jack Ostroff wrote:

There's been an update to the gkrellm mailing list about progress

on the

gtk3 conversion.á It seems much of the work is being done in a

specific

git branch.á If I want to create an ebuild to track that branch

instead

of master, what would be an appropriate numbering of that ebuild?á

Just

using a different name with 9999 would work - but then those two

names

would have to block each other, since I don't think they could
co-exist.á Are there any examples I can look at?á Just adding

something

after the 9999 doesn't seem right, nor does something like 9998.

If upstream is planning a specific version for that branch, it could
be
used, e.g. with Qt we do dev-qt/qtbase-6.8.9999 for EGIT_BRANCH=6.8,
while 6.9999 is Qt6's main development branch.

This is likely what I'll do, at least locally. Historically, there has
been enough activity in master that I wouldn't want to lose that by
just switching 9999 to the new branch. I suspect that there will be
very few if any other users interested, and at least for a while, this
will only track the slow decrease in compile errors, so I don't
actually see much reason to put this new ebuild in the tree. By the
time it actually compiles and runs, I wouldn't be surprised if it gets
merged into master, before becoming an actual release.

Doing it *before* rather than after can also be useful if don't want
that version to come out by default when someone accepts keywords
(aka take normal 9999 instead).

Not great but fwiw dev-vcs/git did do the "add something after" with git-9999{,-r1,-r2,-r3} for branches maint, master, seen, and next
... not quite sure who needs all these but well ;) with -r3 being
the most bleeding edge afaik.

One more option would be to make that branch the 9999 default and
not bother keeping both. I did that with qutebrowser when it switched
to Qt6 until they merged the changes to the main branch.

Ultimately it's not super important though, 9999 ebuilds should be
considered unsupported and is either only for the maintainers to track changes or at most users that know what they're doing. So some
unintuitive versioning isn't the end of the world.

And if that version is going to replace the old eventually, I wouldn't
do invasive workarounds like a separate package that blocks.
--
ionen

Jack

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 16, 2024 at 05:04:43PM -0500, Jack Ostroff wrote:

There's been an update to the gkrellm mailing list about progress on the gtk3 conversion.  It seems much of the work is being done in a specific
git branch.  If I want to create an ebuild to track that branch instead
of master, what would be an appropriate numbering of that ebuild?  Just using a different name with 9999 would work - but then those two names
would have to block each other, since I don't think they could
co-exist.  Are there any examples I can look at?  Just adding something after the 9999 doesn't seem right, nor does something like 9998.

If upstream is planning a specific version for that branch, it could be
used, e.g. with Qt we do dev-qt/qtbase-6.8.9999 for EGIT_BRANCH=6.8,
while 6.9999 is Qt6's main development branch.

Doing it *before* rather than after can also be useful if don't want
that version to come out by default when someone accepts keywords
(aka take normal 9999 instead).

Not great but fwiw dev-vcs/git did do the "add something after" with git-9999{,-r1,-r2,-r3} for branches maint, master, seen, and next
... not quite sure who needs all these but well ;) with -r3 being
the most bleeding edge afaik.

One more option would be to make that branch the 9999 default and
not bother keeping both. I did that with qutebrowser when it switched
to Qt6 until they merged the changes to the main branch.

Ultimately it's not super important though, 9999 ebuilds should be
considered unsupported and is either only for the maintainers to track
changes or at most users that know what they're doing. So some
unintuitive versioning isn't the end of the world.

And if that version is going to replace the old eventually, I wouldn't
do invasive workarounds like a separate package that blocks.
--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmc5HdAACgkQskQGsLCs QzSU3Qf/Zvk0UBJ/dkF+5VckWDjKJL8AYxGbd0ti9KacO9zSzirE84pqE24/rw39 zBOVid3eVLFRbC2KijvaS7nFf0ejt/7U9qMR9IGC3VVhAQ09Cjr5gNXACNUcdmnT 1iJtkmytZd+9aZtZTHVU8a0au3CW5XZ/ap15FRsixy4Mcld0WuVH5QA/aH5UuIko bJvQzYOUXlHHOh/AjpXx+z6ZcBIXv0sAzWoFVT+3jgXzQOgsMcUSC2s7H0bfFsqn xp9Vapx85AMdOcoTfZlpkd1WRYd5hLByGIR4u9jlbQSBdFKRYAo/eDkkSPtPiIKb C1+IxFzKOjI/kP5Q+dei8dzLHj5cJA==
=+yKT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)