GF release 3.11 #85
Comments
|
Yes, definitely time for a release! Thanks for the initiative 🎉 Milestones
(Anyone else who is working on RGL, let us know if you're in the middle of something, or just discovered a massive bug you want to fix for the release!) |
|
Yes, an excellent initiative! If this version is 3.11 then the next one will of course be GF 95 😊
Bringing the test suite up to date and hosting binaries on GitHub are excellent ideas. How is it with the main web page? Should it also be hosted on GitHub? To avoid downtimes and minimize maintenance load. This would not solve it for the GF Cloud, but would at least guarantee access to the other things.
Somehow I don't think RGL should stop releases, since it is an independent project following lots of parallel tracks. My own plan is to work on the Extend module, at last, now to make sure it can implement what is needed in the ParseExtend module in gf-wordnet. This would speed up porting the WordNet grammar to new languages and eliminate duplicate work.
The gf-wordnet grammar and lexicon itself is taking the role that the wide-coverage translator once had. But I think it should also be seen independently of GF, and also of RGL.
Morphological lexica is another project I have been gradually developing, and I think it should become a part of the standard RGL, so that one can easily pick words with their inflections, using native names as keys. This is simply an extension of the Irreg modules, where all we care about are the morphological properties of words, not their senses, English equivalents, or subcategorization patterns (which is done in gf-wordnet). When working with application grammars, I find myself constantly importing these dictionaries, and have to create specific paths for them since they are not in the standard RGL yet. The emerging modules are in gf-rgl/src/morphodict/. Needless to say, GF 3.11 should not wait for this project either.
Regards
Aarne.
…________________________________
From: Inari Listenmaa <[email protected]>
Sent: Wednesday, November 11, 2020 8:32:12 AM
To: GrammaticalFramework/gf-core
Cc: Subscribed
Subject: Re: [GrammaticalFramework/gf-core] Next GF release (#85)
Yes, definitely time for a release! Thanks for the initiative 🎉
I agree with your suggestions, here are a few comments on milestones.
Milestones
* Test suite fixing is happening here<https://github.com/kharus/gf-core/tree/enable-tests>, looking good except for some problems with the RGL path.
* Regarding RGL milestones, I think @bamutra<https://github.com/bamutra> is actively developing Runyankore resource grammar. How is that development looking, would it make sense to wait for some significant improvements for a new release, or just take it in whatever shape it is?
(Anyone else who is working on RGL, let us know if you're in the middle of something, or just discovered a massive bug you want to fix for the release!)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#85 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAWBQXNQGKQJKQOTK3TIX4LSPI4XZANCNFSM4TRBQEJQ>.
|
|
A bolder suggestion is then that the GF packages should not include any RGL at all. To me this makes more sense than including a snapshot of whatever the RGL happened to be on the day of the release, and reinforces the separation between the projects. Actually, as I look into it, this is already the case for some of the packages, e.g. the Debian package contains no RGL but the Windows one does, even though this information is not actually communicated on the GF download page. So, my suggestion is that to make everything consistent, we provide the following GF binary packages, none of which include RGL:
Notably: I don't know why there currently is a GF binary for Raspbian, and I think we should drop it since I don't know to create it and I don't know if there's any demand for it. In addition to the above, we also need to set up a GitHub Actions workflow in the |
|
Update: the RGL workflow is under development here |
|
Dear All,
I am in support of having GF-core and gf-rgl separate because I think their release cycles are quite different. Regarding the rukiga RGL, I am still working on it so it can wait for the next RGL release. We could have it released in its current version with an expected update at the next release cycle.
Regards,
David
On 11 Nov 2020, at 23:28, John J. Camilleri <[email protected]<mailto:[email protected]>> wrote:
A bolder suggestion is then that the GF packages should not include any RGL at all. To me this makes more sense than including a snapshot of whatever the RGL happened to be on the day of the release, and reinforces the separation between the projects. Actually, as I look into it, this is already the case for some of the packages, e.g. the Debian package contains no RGL but the Windows one does, even though this information is not actually communicated on the GF download page. So, my suggestion is that to make everything consistent, we provide the following GF binary packages, none of which include RGL:
* macOS (.pkg)
This is built using make pkg, I am working on a GitHub Actions workflow which does this (here<https://github.com/GrammaticalFramework/gf-core/actions?query=workflow%3A%22Build+macOS+Package%22>).
* Debian (.deb)
This is built using make deb, I wrote a workflow which does this (here<https://github.com/GrammaticalFramework/gf-core/actions?query=workflow%3A%22Build+Debian+Package%22>) although I don't know how to produce both 32-bit and 64-bit versions.
* Windows (.zip)
I'm not sure how this is built, there doesn't seem to be any script for this in the repository. I can start experimenting with a workflow for this too but will likely need some help.
Notably: I don't know why there currently is a GF binary for Raspbian, and I think we should drop it since I don't know to create it and I don't know if there's any demand for it.
In addition to the above, we also need to set up a GitHub Actions workflow in the gf-rgl repository which builds compiled versions of the RGL, and then have some sort of regular release cycle there so that it is easy to grab a not-too-old binary snapshot of the RGL.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#85 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFID7QXSD5FMJFXFEMDTIFLSPLXVDANCNFSM4TRBQEJQ>.
|
|
I'm fine with the GF binary package not including RGL and dropping the Raspbian package. |
|
One should just still make it clear that people are recommended to install the RGL, and make it as easy as it is now with automated setting of GF_LIB_PATH etc.
…________________________________
From: Inari Listenmaa <[email protected]>
Sent: Thursday, November 12, 2020 8:22:38 AM
To: GrammaticalFramework/gf-core
Cc: Aarne Ranta; Comment
Subject: Re: [GrammaticalFramework/gf-core] Next GF release (#85)
I'm fine with the GF binary package not including RGL and dropping the Raspbian package.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#85 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAWBQXMGVQRYR3JAFKR3B3TSPOEL5ANCNFSM4TRBQEJQ>.
|
|
Notably: I don't know why there currently is a GF binary for Raspbian, and
I think we should drop it since I don't know to create it and I don't know
if there's any demand for it.
Thomas had a Raspberry PI and he built GF on it. If someone else wants it
in the future then he/she can build it himself/herself.
|
|
Some small updates:
|
|
On a slightly related note, I've made nix-expressions for building GF. They are available here: https://github.com/anka-213/cclaw-nix-stuff. There is still some work to do, but it is an easy way to install GF with dependencies if you have nix. |
|
@anka-213 I still don't really understand what nix is (🙈). Is your work something that can and should be included in the release somehow? Or maybe the installation page should link to your work? |
|
No worries, you don't need to include anything. 😄 Nix is a package manager, kind of like pacman or apt, but declarative. My nix expressions is code that can be used for building the project (or downloading binaries that were previously built with these expressions). Nix supports Mac and Linux, but unfortunately not windows (outside WSL). See here for more info: https://nixos.org/ So the later option might be the most useful. I should name the project something better though. 😛 Another thing I could do is to submit this to the official nix package repository, so it can be installed using |
|
Right, ok! Whenever you do that, you can then add some instructions on the GF web page, namely in |
|
I have gone through all the commit messages since the last release and tried to update the changelog for 3.11 accordingly, see |
|
Great! To my eye it looks good, but I may also have missed some things other people have been doing in the past 2 years. |
What is the status of the MacOS build scripts? What problems does it have? |
|
I don't think there are any problems remaining, as per my message on 2020-11-17. |
|
Can you write a check-list of what remains to be done for the release?
|
|
Yes, a checklist is a good idea. I'm not too sure of everything it should contain, but here's my first sketch of what should make it into the release. I think what gets added to (or removed from) this list should be a community effort. Must have
Nice to have
|
|
I created a PR to fix Ubuntu failures on the "Build Ubuntu package" workflow: |
|
Great work on the release, guys! 🥂 |
|
Actually, I noticed one thing: the
|
|
We didn't release on Hackage yet, just wanted to put binaries out for the summer school. I have no idea on the -git suffix or whether it will be a problem for Hackage (or for anything else). |
|
Since We could either manually set the version number right before a release and then change it back to a pre-release style number immediately after or try to automate the process. |
|
@johnjcamilleri can you do the last step and upload to Hackage? Is there anything you're missing or need others to do? |
|
Trying to upload to Hackage, I get this:
I'm investigating further. |
|
I had more luck creating the source distribution tarball with There's now a release candidate here: https://hackage.haskell.org/package/gf-3.11.0/candidate which I have successfully installed inside a Docker container. Maybe someone else can review it, then we can publish it for real. |
|
BUT |
|
Ok, the above problem is fixed and a new release candidate is uploaded to Hackage. There is still some mystery surrounding the way
I suspect this has something to do with what WebSetup does... |
|
So I published the package on Hackage package as 3.11.0. So I uploaded version 3.11 to Hackage too, and marked 3.11.0 as deprecated (since you can't delete it once it's published). They are exactly the same version in terms of source code. Hope this doesn't cause too much confusion (I knew something would go wrong...) |
|
Haha, that's a very minor thing to me! I uncommented the Hackage instructions from the documentation at 8ec13b1 , feel free to update if something is still out of date. |
It feels like the time is becoming [over?]ripe for a new GF release. There's a number of issues/suggestions that I think should be discussed, which is the purpose of this issue.
Version number and milestones
I guess 3.11 should be the next version, that's probably uncontroversial.
We need to decide what milestones we want included in the release. I can think of at least 2 which @inariksit has mentioned elsewhere:
Also, the GF binaries include pre-compiled RGL, so we need to decide if there are any upcoming RGL milestones which should block the release.
Release recipe
I think we should document the exact steps to make a release in some appropriately named file like
RELEASE.md.Previously @Thomas-H has taken care of releases, but since he is no longer actively working with GF it is even more important that all information is recorded somewhere.
Some things which this needs to include:
-gitsuffix ingf.cabal)Hosting binaries on GitHub
Until now, the binaries have been built locally by Thomas and then uploaded to www.grammaticalframework.org. I believe that for the next release, we should have everything built on GitHub and host the binaries there too. Of course we can copy them to the GF server, in case we one day do not use GitHub anymore, but the recent GF server outage has shown that we need to have them stored elsewhere.
I have written GitHub Actions workflows for building Debian and macOS packages (the latter still needs some work). I am hoping it will then be easy to attach those generated artifacts to the releases in GitHub although I don't know too much about this, maybe someone else is willing to help out here.
The text was updated successfully, but these errors were encountered: