<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 26, 2020 at 2:33 AM Caleb Maclennan <<a href="mailto:caleb@alerque.com">caleb@alerque.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Apr 25, 2020 at 11:50 PM Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org" target="_blank">karl@kleinpaste.org</a>> wrote:<br>
> - 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?<br>
<br>
Yes, just simply tag, then build. There should be virtually nothing to do.<br>
<br>
In fact it's kind of important you don't do anything else. If you tag<br>
a commit as, say, "v4.2.0", then realize you forgot something and<br>
commit a small change, then build, what you build won't be v4.2.0 at<br>
all it will be v4.2.0.1. In other words to get the actual release<br>
version as tagged you _must_ build from the actual tagged commit. You<br>
can't fudge and actually build something else and just call it<br>
something its not.<br></blockquote><div><br></div><div>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</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
By the way I would be inclined to make the next release v4.2.0 not<br>
v4.1.1. If you actually follow SemVer there are a lot more changes<br>
than should fit in only a patch version bump. As a distro packager I<br>
expect patch versions to build and install virtually identically to<br>
previous versions. This release will require an entirely new set of<br>
build commands, and even the dependencies have changed. Even if there<br>
is not a much in the way of user facing changes the under-the-hood<br>
stuff is radically different and shouldn't be hidden behind a patch<br>
release number bump — at least not in my opinion as a downstream<br>
packager.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>--Greg<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
_______________________________________________<br>
xiphos-devel mailing list<br>
<a href="mailto:xiphos-devel@crosswire.org" target="_blank">xiphos-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/xiphos-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/xiphos-devel</a><br>
</blockquote></div></div>