Hi,
All in all, from my understanding, one main “blocker” for
switching
appears to me;
the repositories at
https://git.bioconductor.org/package/NAME do not
tag package versions. The only method of organization
is branches
that are named after *Bioconductor releases* (not
package releases),
e.g. RELEASE_3_15. We can only determine the package
version by
reading its DESCRIPTION file or by looking up the
version index for
all Bioconductor packages (we do that already). This
means that there
could be different commits for the same package version
in the same
release branch — so we have to include the commit hash
and a revision
counter in the version string.
Yes, this is the main obstacle.
We will need a new way to refer to versions. This must
incorporate the
Bioconductor release (as an epoch-like prefix or as a suffix or
just as
a property?), the package version, a revision identifier, and a
commit
stub. Are we okay with this? It would be ugly and inconvenient
to
include the Bioconductor release in the version string. It's also
a bit
ugly to include a revision and a bit of the commit when in most
cases we
just have a pretty release version.
The updater will need to update revision numbers when the version
according to DESCRIPTION has not changed, but a new commit is
used.
Does the top commit in a Bioconductor release branch *always*
correspond
to a package release, or can there be experimentation or
development on
these branches?
I no longer remember why we haven't switched to using this WIP
commit.
It looks like it's only a cosmetic problem.
I'm not sure if we can only use it for guix-bioc without causing
problems with the (gnu packages bioconductor) module. Any
thoughts on that?
If we can use it for guix-bioc without impacting (gnu packages
bioconductor) I'm all for trying it --- but I have to respectfully
decline doing the work myself this time. I can certainly assist
with
diagnosis of problems that stem from adopting the WIP patch.
--
Ricardo
