Re: [xiphos-devel] getting a new release out
On Sun, Apr 26, 2020, 02:55 Caleb Maclennan wrote: > On Sun, Apr 26, 2020 at 10:39 AM Greg Hellings > 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@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sun, Apr 26, 2020 at 10:39 AM Greg Hellings 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? > 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? > 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@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sun, Apr 26, 2020 at 2:33 AM Caleb Maclennan wrote: > On Sat, Apr 25, 2020 at 11:50 PM Karl Kleinpaste > 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. --Greg > > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sat, Apr 25, 2020 at 11:50 PM Karl Kleinpaste 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. 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. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sat, Apr 25, 2020 at 5:43 PM Karl Kleinpaste wrote: > On 4/25/20 4:55 PM, Greg Hellings wrote: > > If you can mutter the proper svn command > > > I was thinking of downgrading xiphos/src/main/display.cc during build to > undo the fix I did. But if you want to incorporate Troy's fix from Sword, > then you can get it with "svn diff -r3718:3721". Those are the Apr 18 > commits. > Builds for F30-F32 and Rawhide are on their way to updates-testing, so that's going to be taken care of very shortly. We can do an update to the build scripts to ensure we get that version of mingw-sword when it lands. --Greg > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On 4/25/20 4:55 PM, Greg Hellings wrote: > If you can mutter the proper svn command I was thinking of downgrading xiphos/src/main/display.cc during build to undo the fix I did. But if you want to incorporate Troy's fix from Sword, then you can get it with "svn diff -r3718:3721". Those are the Apr 18 commits. ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] getting a new release out
On Sat, Apr 25, 2020 at 3:50 PM Karl Kleinpaste wrote: > It's been over 2 years since 4.1.0. Obviously, that's way too long. This > is my fault, of course. > > In this time, we've gotten a new build system, and there's been a slew of > bug fixes. Nothing new and huge, architecturally speaking, the way that > (say) av11n kicked us up to v4, for example. So what needs to go out is > 4.1.1. I have thoughts about bigger things that need to be done afterward > (notably, the editor; and Abbrev needs a serious re-work) that might lead > to enough change to justify calling it 4.2. > > From today's state of things, what needs to be done before we can put out > 4.1.1? > > - For any Xiphos release prior to the next Sword release, ours needs to > include the intro material revert .diff. > If you can mutter the proper svn command to me or post the actual diff file here, I can get that added to both MinGW and native Fedora packages. Other packagers might appreciate it, too - There may be some peculiar machinations around Windows build due to that > diff, the current state of other mingw packages (BibleSync needs to be > built with Xiphos right now), and maybe Greg knows of other things. > I know of thing else regarding Windows that *needs* to happen - 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? > I'm working on fully automating that, so all you have to do is tag the commit in the repo and it will do all the releasing for you. Look for a PR in the next few days to handle that. Once that's done a release will be as simple as: git tag v4.1.1 git push --tag --Greg > > Anything else? Any reason we couldn't let 4.1.1 out the door before week's > end? > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
