Clarifying the release schedule

[gnikonorov]

Hi everyone.

I think it may make sense to create a release schedule. I looked at PyPI and it looks like we haven't released a new version of this plugin since March of this year.

While we're at it, perhaps it would make sense to automate the process as much as possible and create a RELEASING.rst doc similar to pytest's. This way users could be aware of what to expect in terms of feature delivery.

Thoughts @ssbarnea @BeyondEvil @davehunt ?

[BeyondEvil]

I'm no fan of release schedules for relatively small projects. They make sense for larger projects that have a roadmap.

As for "automatic" releases, I highly recommend Semantic Release we use it heavily at work (and it's not only for npm projects).

Easy to enforce in PRs using this Github app.

[gnikonorov]

I'm no fan of release schedules for relatively small projects. They make sense for larger projects that have a roadmap.

You're right. It probably doesn't make sense for this plugin now that I think about it.

As for "automatic" releases, I highly recommend Semantic Release we use it heavily at work (and it's not only for npm projects).

This looks awesome! So it would be part of our pipeline, and then a separate step could publish the build product to PyPI right?

Also, can we publish a package now in the meantime since it's been a while and the changelog has a few unreleased items in it? I would do it, but I don't think I have the permission to.

[BeyondEvil]

As for "automatic" releases, I highly recommend Semantic Release we use it heavily at work (and it's not only for npm projects).

This looks awesome! So it would be part of our pipeline, and then a separate step could publish the build product to PyPI right?

So, high level, this is how it works:

On every merge to the default branch (in our case master) Semantic Release is run. If it determines a release can be made (by scanning all the commits since last tag) it will create and push a new tag.

This tag will then trigger a workflow which publishes a package to PyPi.

Since I have experience with this, I'm happy to set it up if it makes sense to you and @ssbarnea.

Also, can we publish a package now in the meantime since it's been a while and the changelog has a few unreleased items in it? I would do it, but I don't think I have the permission to.

Sure! You can follow the steps here and I help you if you get stuck. 👍

[gnikonorov]

Sure! You can follow the steps here and I help you if you get stuck. 👍

Thanks @BeyondEvil ! This weekend I'm going to submit a PR to release 3.0.0 then. We need a major bump because of #347. Does anyone have any objections?

[BeyondEvil]

Sounds good @gnikonorov 👍

[gnikonorov]

I think it makes sense to wait for #360 to merge before we release so we can test the new release workflow

[gnikonorov]

On second thought I think we should release now.

[gnikonorov]

I want to try and get a release out this weekend

@ssbarnea, @BeyondEvil did you want to wait for #361 before we release. Or do we want to go ahead regardless of the status of the PR

[ssbarnea]

On community maintained open-source project a "schedule" is unrealistic. I can be today, slip to next month or never, based on who needs it more. There is no value in documenting something that nobody can follow.

Yep, I was waiting for the other patches merged before tagging a new pre-release. Pre-release are cheap and safe to make because users do not get access to them unless they specify the version explicitly or use the --pre argument on pip.

[gnikonorov]

@ssbarnea can we do a release now instead of waiting? We haven't released since March and we have unreleased bug fixes that I would like to release if possible.

[BeyondEvil]

Go head and start on a release @gnikonorov 👍