Seed: Semantic versioning

[flosse]

Is there a reason not to do Semantic Versioning?

[David-OConnor]

As I understand it, that would mean each breaking change gets a new major version; moving too fast at this time, but definitely long-term... but have been upping it too gradually. Thoughts on how we should effectively use it?

[flosse]

Luckily there are an unlimited amount of numbers in the universe ;-)
But as far as I understand there is a distinction between the development (0.y.z) and stable (x.y.z) versions.
So during the development phase we increase y on every breaking change. So instead of increasing v0.4.1 to v0.4.2 we would now have v0.5.0 because there were breaking changes.

[David-OConnor]

I like that. Let's do it from here on. Ie last rel could have been 0.5.0 due to the breaking Init and routing option changes.

[MartinKavik]

Some people (I assume also David) use development versions (0.y.z) in other way - y is for milestones / big improvements and z for everything else.
But yeah, I'm also fan of semver.

While we are talking about versions - it would be nice to have something like [unreleased] at the top of changelog. E.g.:

# Changelog

## [unreleased]
- xxx

## v0.4.2
- Added an `Init` struct, which can help with initial routing (Breaking)
- The `routes` function now returns an `Option<Msg>` (Breaking)
- Updated `Tag::from()` to accept more input types
- xxx

## v0.4.1
- Added more SVG `At` variants
- Added the `St` enum, for style keys; similar to `At`
- xxx

[David-OConnor]

Yea - was using the milestone approach. By that measure though, I think the last one could have been 0.5.0 too! I think semvar is a more standard approach though, now that @flosse brought it up.

Agree on unreleased. And I've been sloppy in the guide lately about including unreleased changes. (Although it's now in sync)

[MartinKavik]

I suggest to close it. Changelog is updated and we agreed to use semvar on stable (x.y.z) versions.

[flosse]

I'd still expect that an update from v0.5.0 to v0.5.1 has no breaking changes.
Whats the reason not to publish a v0.6.0 instead?

[David-OConnor]

Agree; probably should have been 0.6.0; old habits.

[MartinKavik]

Maybe we should create an issue like Version 0.6.0 will be released before the next release - so we can polish details, wait for almost complete PRs, prevent old habits, prepare docs, etc.

[MartinKavik]

@David-OConnor Create that issue ^ please once you are ready for the next release. Maybe we should update seed-rs.org guides in a standalone branch and publish it together with the new Seed version.

And I think we can close this issue again.

[MartinKavik]

We had some smaller problems during the release - https://github.com/seed-rs/seed-quickstart/issues/14 - so I'll leave it open for the next round.