release's Introduction

Release process

Since gtk-rs has multiple crates which have inter-dependencies, it's a bit painful to make a new release. So here are the multiple steps:

Get the current version for all crates (all crates in one repository should all have the same!).
Replace git dependencies with crates.io ones.
Push those changes to a branch with MAJOR.MEDIUM name.
Push tags.
Write a blog post (add the file into _posts folder in gtk-rs.github.io repository) announcing the new release.
Publish crates.
Update dev branch crates' version.

Note that the github token is used for two things:

Gathering the merged pull requests.
Opening pull requests (for the version updates).

Using this tool

I don't recommend it if you're not a member of the gtk-rs organization but just in case:

python3 src/release.py -m MEDIUM -t [Your github token here]

release's People

Contributors

Stargazers

Watchers

release's Issues

Add newline at the end of Cargo.toml when missing

Add option to only update badges

Sort contributors alphabetically when generating blog post

New release

If any other issues/PRs should be solved for this release please add them below as comment.

Add PRs from gir as well for the blog post

Bad message indent

All done with the "lgpl-docs" update: please merge the PR then press ENTER so the                publication can performed...

Cleanup: put arguments parsing into its own file

And also put the arguments inside a class. Again: simpler to maintain.

When generating docs, it'd be nice to generate sources as well

For the moment, all [src] links are broken.

Fix examples merge (pending should be merged into master, not the opposite)

Generate different commit message for dependencies version update and lib version update

Currently it's "Update versions [ci skip]" for both, which isn't very helpful...

gtk-test repository should be released through this script as well

Basically, it requires to update the crate version (in both master and crate branches) and to update dependencies (in crate branch). Then it'd open the PR and here we go!

Add CI with pylint (and fix all pylint warnings)

Add messages to tell what's going on when generating docs

Most of the build is spent on Cloning "lgpl-docs" from "https://github.com/gtk-rs/lgpl-docs", which isn't very nice nor informative.

Generated documentation source view only contains last generated crate files

Need to write a minifier since minification is disabled

In order to be able to merge "search-index.js" files, I needed to disable minification. I just need to write a wrapper above the minifier-rs crate used by rustdoc in order to have back again in here as well.

Add tags on release branches when releasing

Display message when publishing crates to know which one is being published

glib has to be published before cairo-sys

Add wait time between two publications to let crates.io update its cache or whatever...

lgpl-docs publish step is failing

This repository doesn't have a crate branch so it shouldn't try to check it out.

Documentation: crates files aren't correctly added!

New release

We should get a new release of every crate out soonish. Let's collect all issues that we want to have fixed before that. @GuillaumeGomez @EPashkin, please edit this issue description and add the things you care about.

Cleanup: put most functions into a class

It'll allow to remove the globals once and for all.

Change the cced people on created PRs

For now, sdroege is missing.

Check if bug "gir-files/*" comes from here

It adds = at the end of the line?

When doc is generated, links aren't made between crates' types

To solve this issue, I need to generate all docs by remove the corresponding option and then only copy the current crate's files.

Remove ironman-machine from contributors in blog post

Open a new issue here to track what's missing for next release

Like #94

Fix gir blog post links

For now they're generated a bit weirdly...

Proposal for new release process supporting multiple versions

Currently the release process only supports a single version at a time, with no possibility to backport bugfixes to older releases.

For example, there may be many features and fixes going into a gtk crate version 0.7.0 from 0.6.0. Behavior can break between the two versions. The current release process does not have a way to support both an 0.7.x and 0.6.x release simultaneously; all fixes would be restricted to the 0.7.x line.

The main issue is the branch structure. @sdroege proposed in gtk-rs/glib#294 that rather than having a master and crate branch per repository, it could be expanded to master and 0.6.x branch and 0.7.x branch, adding a new branch for each feature release. Then bugfixes could be backported as desired from master or 0.7.x back to the 0.6.x branch. (And remove the crate branch.)

Of course this branch structure would not require maintainers to begin supporting more old versions; but it would be nice to have the option, in case that becomes desirable in the future.

The release process would be:

master branch always contains an alpha version, e.g. 0.7.0-alpha
When it's time to release 0.7.0, create the branch 0.7.x from master
On the 0.7.x branch, change the version from 0.7.0-alpha to 0.7.0
On the master branch, change the version from 0.7.0-alpha to 0.8.0-alpha
Publish to crates.io from the relevant branch, 0.7.x
Future bugfixes can be cherry-picked from master or other places back into 0.7.x branch, and version bumped to 0.7.1 for a bugfix release

Skip CI for generated PRs

.. to minimize its queue.
Both travis and appveyor seems understand "[ci skip]" in commit message.

@GuillaumeGomez, @sdroege what you think?

New releases

As discussed with @GuillaumeGomez , a new set of releases this weekend would be nice. From what I can see, everything we wanted included is there now (except for the callback guards that had to be added back because of Rust 1.24.1, that can wait until 1.25/1.26).

@EPashkin @tmiasko @MathieuDuponchelle ?

Badges aren't updated on gtk-rs.org

Create a branch bound to a version when making a release

When releasing 0.5 for example, it'd be nice to have a 0.5 branch created on the repository (as discussed before in #21).

fix search-index.js generation

search-index.js is now a bit different so any line not starting with [ should be kept.

Create multiple tags if more than one crate in a repository

In cairo, sourceviez and sys repositories, multiple crates are in one repository, which is problematic for the tagging. I think we should put sys crates behind a tag like crate-sys-version and don't change anything for "main" crate.

Original discussion can be found here: gtk-rs/sys#109

Check what happens if a crate hasn't been released yet

It'll be needed for gdkx11

Proposal for change strategy for version update in Cargo.tom

Currently we (script) open single crate Cargo.toml, iterate through dependencies and increase it depending by UpdateType (major/medium/minor), then same process repeated for all crates.

I propose separate version increasing and applying:

Add config with versions for all your crates (maybe just to consts.CRATE_LIST)
On release first thing is update this config by release type (UpdateType) or even manually if we need update only one crate
For each crates we synchronize version with configured (for both package version and dependencies)

With this we can handle versioning more independently.
Also for one crate will be used same version in all dependents.

cc @GuillaumeGomez, @sdroege

Bump version in master after new release

Sort pull requests in reverse number order (to go from oldest to newest)

New release

Tracker for all issues that should be solved before the next release. Please add anything you want to have considered in a comment below.

Make an option to only "work on" given crates

The flag would be --pick-crates and it would ask the user for each crate if they want it to be included for the rest. It would allow to run only for sys crates for example.

Usage '[patch.*]` report

@GuillaumeGomez, @sdroege
I tried use [patch.crates-io] in gtk-rs crates to minimize difference between master and crate branches.
See my test forks https://github.com/EPashkin/examples/tree/as_master,
https://github.com/EPashkin/rust-gnome-sys/tree/as_crate,
https://github.com/EPashkin/glib/tree/as_crate,
https://github.com/EPashkin/cairo/tree/as_crate,
https://github.com/EPashkin/gtk/tree/as_crate
As I used only part crates there there too many [path.*] section in Cargo.toml,
in gtk-rs IMHO it will be only [patch.crates-io].

It works fine until I tried emulate glib version upgrade from 0.6.0 to 0.7.0:
examples tries build both current and next version,
as there already many cons found I stopped checks.

Pros: difference only [patch.crates-io] section,
also as this sections ignored in dependencies IMHO possible just publish crate from master branch

Cons:

Totally incompatible with .cargo\config\path: cargo not allow mixing.
If someone want use git version then he need use [patch.crates-io] too.
Related errors unclear: in next error "0.7.0" is version of conflicting sys (not sure which)

error: failed to select a version for `gtk`.
    ... required by package `gtk-rs-examples v0.0.1 (file:///D:/eap/rust/0/examples)`
versions that meet the requirements `^0` are: 0.7.0

the package `gtk-rs-examples` depends on `gtk`, with features: `v3_22, v3_16, v3_20, v3_10, v3_22_30, v3_18` but `gtk` does not have these features.

gtk-rs / release Goto Github PK

release's Introduction

Release process

Using this tool

release's People

Contributors

Stargazers

Watchers

Forkers

release's Issues

Recommend Projects

Recommend Topics

Recommend Org