Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidelines for releases #17

Open
ftyers opened this issue Jul 6, 2020 · 3 comments
Open

Guidelines for releases #17

ftyers opened this issue Jul 6, 2020 · 3 comments

Comments

@ftyers
Copy link
Member

ftyers commented Jul 6, 2020

We should write some general guidelines for releases.

@TinoDidriksen
Copy link
Member

Some exist, but need major surgery:

@flammie
Copy link
Member

flammie commented Jul 6, 2020

I think in current ecosystem it would make sense to have ~standard ci test suite to pass prior to release. There's a whole bunch of different attempts for tests (make check style) in various languages and pairs we just need to figure out the best and most generic one. Particularly I think the current Release policy list:

  • Testvoc should be clean
  • Whether it compiles and runs with the latest release of apertium/lttoolbox (and other required packages)
  • Whether it compiles and installs correctly as a tarball created with make dist (see Making_a_release#Testing)
  • If there are regression tests, check that these pass
  • Run a corpus through it, and ensure there are no debug symbols (#, @)

can be easily automated as ci test.

@TinoDidriksen
Copy link
Member

Currently, I do the middle 3 (builds with release versions; builds from tarball; run make test) as part of the packaging work. I assume language devs have done testvoc and corpus to their own standards before they hand it off to me.

But yes, this can be automated. apertium/packaging#16 is also relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants