search

purebred-mua / purebred

A terminal based mail user agent based on notmuch
GNU Affero General Public License v3.0
139 stars 19 forks source link

decide versioning scheme #483

Closed frasertweedale closed 1 year ago

frasertweedale commented 1 year ago

Is your feature request related to a problem? Please describe.

We should claim the /purebred/ package name on hackage. To do that we need a release (or a candidate release, to at least claim the package name). Before we do that we should decide upon a versioning scheme.

Describe the solution you'd like

Releases will be sporadic and will usually break compatibility in some way (of the library, the configuration data type, or the behaviour of the program). I suggest the following scheme:

<year>.<releasenum>[.<patchnum>], e.g. 2022.1 for the first release in 2022, 2022.2 for the second release in 2022, and 2022.n.p for bugfix releases that don't break API or config in any way.

This scheme is PVP and semver compliant. If that even matters for a user application (as opposed to library). But I reckon it does to some extent, given that we want to encourage plugins.

Describe alternatives you've considered

Instead of year we could just increment the first version component for each "major" release. E.g. 1.0 then 2.0 and so on, with patch level releases being n.0.p. This scheme has an unused second version component (for PVP compliance).

Or we could use 0.n.p or 1.n.p and stay at "version 0" or "version 1" until we decide to become "the next major version". This scheme avoids unused version components. But it has some mysterious meaning ascribed to the first version component. What circumstances warrant a bump from v.n[.p] to (v+1).0? It might be better to avoid the question :)

frasertweedale commented 1 year ago

@romanofski let me know your thoughts.

romanofski commented 1 year ago

Yeah I was wondering do we want to expose that it's still work in progress or just release 1.0 and say good enough and use the normal major/minor/patch scheme? Or in other words, if we use <year>.<releasenum>[.<patchnum>] would we want to stick with it or just until we release 1.0?

frasertweedale commented 1 year ago

@romanofski I want to decide the permanent scheme. We can stick with 1.x etc (fair enough, we already defined milestones as such). But I was thinking about the meaning (or lack of) implied by different schemes and what actually makes the most sense. So, just let me know what you think works best or provide your thoughts on the advantages/disadvantages of the different options.

romanofski commented 1 year ago

Ah understood. I agree with the <year>.<releasenum>[.<patchnum>] conveying a bit of a slow release cycle and I think that's a good idea. Renaming our current release milestones is simple, so I don't think we should be holding off on any different versioning scheme really.

So happy to go ahead with your initial idea really. I haven't made a Fedora package release for ages since the last time I ran into conflicts. I'm not sure if I'm still keen to keep it up ... Regardless, nothing to do with a hackage release.

frasertweedale commented 1 year ago

Fixed in https://github.com/purebred-mua/purebred/pull/484.