Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tighten up conceptual model for (our) 2.0 #50

Open
bitprophet opened this issue Apr 29, 2016 · 2 comments
Open

Tighten up conceptual model for (our) 2.0 #50

bitprophet opened this issue Apr 29, 2016 · 2 comments
Milestone

Comments

@bitprophet
Copy link
Owner

bitprophet commented Apr 29, 2016

After #45 it's become more apparent some things are a bit wonky.

The first one that comes to mind is that the major/backported keywords aren't consistent - a 'backported' feature or support item gets put in both bugfix releases and feature releases, but 'major' bugs are only considered "feature-like" and live in feature releases only.

Given the way we treat bugfix/tertiary releases - "feature releases are assumed to include prior bugfixes implicitly" - this seems incorrect. Either that assumption holds or it doesn't. My inclination is that my earlier inclination about 'backported' feature-like issues appearing in both types, is wrong, and all issues should either get displayed "bug-like" or "feature-like" and never both. As-is it makes the changelogs messier and, as noted, is mentally inconsistent.

However changing this would be backwards incompatible (oh the irony) so we'd want there to be a 2.0 release with this sort of change.

Also a good time to more strongly do away with backported/major or e.g. make them distinct issue types of their own like :major-bug: or :minor-feature (though maybe better terms would be nice since that's confusing wrt major/minor release numbering...heh).

And of course, a good excuse to continue the internals cleanup started with #45.

@MinchinWeb
Copy link
Contributor

Rather than hard defining :major-bug: and :minor-feature:, would it make sense (or is it even possible) to arbitrary labels? So at the top of your changelog, have an RST directive like:

.. changelog-role: major-bug
    :display-string: Bug
    :lines: minor

.. changelog-role: breaking-feature
    :display-string: Bug
    :lines: major

.. changelog-role: gui
    :display-string: GUI
    :lines: patch, minor, major

@MinchinWeb
Copy link
Contributor

If we're talking breaking changes, would it make sense to be consistent with SemVer in the use of "major", "minor", and "patch"?

So if the project is currently at 1.2.0, :bug:major would be added to the 2.0.0 release, but not 1.3.0 or 1.2.1 (because 2.0.0 is the next "major" release).

@bitprophet bitprophet added this to the 2.0 milestone Apr 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants