[xiphos-devel] getting a new release out

Greg Hellings greg.hellings at gmail.com
Sun Apr 26 00:38:54 MST 2020

On Sun, Apr 26, 2020 at 2:33 AM Caleb Maclennan <caleb at alerque.com> wrote:

> On Sat, Apr 25, 2020 at 11:50 PM Karl Kleinpaste <karl at kleinpaste.org>
> wrote:
> > - I need to understand how the version stamp thing happens, now that
> Caleb's source_version.txt is in play. We simply tag just prior to doing
> github release?
> Yes, just simply tag, then build. There should be virtually nothing to do.
> In fact it's kind of important you don't do anything else. If you tag
> a commit as, say, "v4.2.0", then realize you forgot something and
> commit a small change, then build, what you build won't be v4.2.0 at
> all it will be v4.2.0.1. In other words to get the actual release
> version as tagged you _must_ build from the actual tagged commit. You
> can't fudge and actually build something else and just call it
> something its not.

We aren't quite there, yet. I have CI passing all builds and creating the
Windows artifacts, but I don't yet have it creating the final build
artifacts for publishing *quite* yet. Not because there's anything wrong,
just because my daughter is back with me this week (she comes and goes
every other week to her mom's) and with her home for school I'll be
focusing on that this week. So I may or may not get to finish release
processing between $dayjob and $dadjob

> By the way I would be inclined to make the next release v4.2.0 not
> v4.1.1. If you actually follow SemVer there are a lot more changes
> than should fit in only a patch version bump. As a distro packager I
> expect patch versions to build and install virtually identically to
> previous versions. This release will require an entirely new set of
> build commands, and even the dependencies have changed. Even if there
> is not a much in the way of user facing changes the under-the-hood
> stuff is radically different and shouldn't be hidden behind a patch
> release number bump — at least not in my opinion as a downstream
> packager.

I would agree with this sentiment. Fedora is a bit loosey-goosey with what
it allows in, but you're not going to slip this past other distros as a
patch release. It really isn't, especially once we tossed in the change
from libgsf to minizip. Let's just cut loose the next version as 4.2.0 and
maybe take the extra few weeks to figure out editor/HTML needs. At least a
roadmap even if we don't finish them in time to make 4.2.0, we can have
4.3.0 well on its way.


> _______________________________________________
> xiphos-devel mailing list
> xiphos-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20200426/27bcdd79/attachment-0001.html>

More information about the xiphos-devel mailing list