continuous delivery for Spoon

[monperrus]

Hi all,

I'd like to propose to set up continuous delivery for Spoon. The idea is that we would do an automated release every month.

Notes:

• we would set up a project spoon-continuous-delivery on SpoonLabs, with a monthly Travis job responsible for making the actual release.
• by default, there would be the automated changelog, but we would have a way to extend it by committing to spoon-continuous-delivery before the due date (eg by committing to spoon-continuous-delivery/changelog/7.3.0.md)
• by default, the last digit of the version would be {year}{month}, eg 7.2.201812. We would change manually major and minor with normal commits on master.

WDYT?

[pvojtechovsky]

I like this idea

[nharrand]

+1

[surli]

I'm personally mixed about that one. I like the concept of continuous delivery in the way "no work to do for the release" I don't like it in the sense "we don't master what will be put in it".

If we release every month automatically, it's basically as if our users are following the snapshot of Spoon. I have the feeling that it will be difficult to guarantee the quality of each release and then it will increase the need for supports.

If we go in that direction, I think we must define clear rules in term of LTS for Spoon, such as announcing which are the version we clearly support.

So personally I'm in favor of doing the work to be able to release very quickly like by pushing a commit, but I don't really see the advantage of releasing every month automatically.

[nharrand]

If we stick with {Major}.{Minor}.{Patch}, we can still:

• Change the Major version when breaking changes occur (on non @Experimental, and non internal api).
• Change the Minor version when we feel like significant new features/bugfixes/modifications have accumulated as currently.
• Change the Patch monthly automatically.

I think a user who updates his/her maven dependency to spoon when a new Minor is published wouldn't be affected.
Only a user who would update automatically for the latest would be affected. But I assume a user that does so is expressing that he/she wants the latest bugfixes ASAP. So I don't feel it is such a contract breach. I would personally, even argue the opposite.
But it adds a granularity layer between Minor and SNAPSHOT.

[surli]

I completely agree on the versioning scheme. And the impact on the users, but I'm not sure to follow exactly what you mean.

From what I understand, you propose that the release job infers automatically the new version number of the release based on what? The label info from the PRs?
Or do you assume that each time we break something we will push the new version number for the release?

[nharrand]

I assumed (but it's just a proposal) that if we leave it alone, the release job would only release a new Patch every month.
But we could manually release Major and Minor when we decide to.

[surli]

the release job would only release a new Patch every month.

yeah but it would be wrong if we'd merge a breaking PR during the month. So we would need to be extra careful on that case.

[nharrand]

Yes for existing API.
We could also progressively increase the use of @Experimental and internal packages, to avoid these problems.

[monperrus]

Just did a manual release myself. Full automation won't be straightforward, and it will take us some releases to get the release script working perfectly :-) But it would really save time. I

@nharrand's proposal makes sense: By default, the release job would only release a new **Patch** every month.

@surli OK for you?

[surli]

As I said, it's ok for me as long as we respect the semantic versioning: the automatic release should take into account the fact that a breaking PR has been merged somehow, to not release a patch version when it's the case.

[monperrus]

the script will implement the rule: if there has been one PR with the label "breaking_pr" in the month, the minor version is increased instead of the patch version.

[surli]

the label "breaking_pr" in the month, the minor version is increased instead of the patch version.

as long as we respect the semantic versioning

it's a really a pain that we don't respect it in this project. We should really reconsider the way we use version numbers. Maybe using a month based numbers or something like this.

But ok, let's try the automatic release system for a while, but I really suggest to be extra careful on what happens on the following months in term of code quality.

[monperrus]

progress at https://github.com/SpoonLabs/spoon-deploy with weekly Travis cron

[monperrus]

almost one year with https://github.com/SpoonLabs/spoon-deploy, it works!