[xiphos-devel] getting a new release out

[Greg Hellings]

On Sun, Apr 26, 2020, 02:55 Caleb Maclennan <caleb at alerque.com> wrote:

> On Sun, Apr 26, 2020 at 10:39 AM Greg Hellings <greg.hellings at gmail.com>
> wrote:
> > We aren't quite there, yet.
>
> Sure we are. But I think we might be talking about different things.
> My comments were all about local tagging and builds. That part should
> be 100% working now, or my job on that PR isn't done. You should be
> able to tag locally, then build and get the right release version.
> This can be tested just by `git tag`, then build and run it and see
> what version it says it is. `make -C build source_package` should also
> have the right filename. (Be sure to delete any such test tags before
> pushing!)
>
> What you are talking about is automating the builds on Github when a
> tag is pushed to the remote repository so there is no local build step
> needed. Great work on that and sorry I havn't been more help by the
> way. That's the part you mean is not quite there yet, correct?
>

Correct. Currently he can tag and do build, then upload. I'm very close to
getting the release process down to tag, push tag, relax with family while
GA does builds and uploads.


> > 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.
>
> I haven't looked at your code yet, but I assume you are building and
> posting artifacts on all [push, pull_request] jobs, but filtering `on:
> push: tags: [ "v*" ]` and running an extra job on them to post the
> correct artifacts to a Github release matching the tag ... correct? Or
> at least that's the goal, no?
>

That is the goal. Currently I have Windows artifacts building and stashing
on every commit or tag. I also have Linux builds completing.

All that remains is adding the Linux artifact stashing and releasing on tag
events. That's just a matter of about four more steps in Github, but I got
distracted by sleep, which I'm about to do again. 😂


> > 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.
>
> I definitely don't want to hold up the release any longer than it
> needs to be and I'm not advocating for stuffing new features in to
> make it worthy of a minor version number bump, all I'm saying is that
> it already needs at least a minor version bump with what's in the
> release so far. The editor can go in 4.3. I wouldn't put anything else
> on the roadmap for 4.2 other than getting the build and release
> process ironed out.
>
> _______________________________________________
> 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/67b2c599/attachment.html>