'Initial' bugs (vs features) break newer release-line-oriented achitecture

[bitprophet]

Description

Bugs (explicit or implicit-because-no-issue-role, doesn't matter) listed at the beginning of time before any release entries, break after Releases 1.1.x because the new "derive default version spec for issues" functionality assumes there will always be more than zero line buckets.

This doesn't break for features because their branch in default_spec() is more generic, just taking the major number only (which is filled in by the pre-seeking functionality). But the bug branch looks inside the major-version structures and tries to find out what the latest minor release bucket is. When there are none, kaboom:

Exception occurred:
  File "/Users/jforcier/Code/oss/releases/releases/models.py", line 88, in default_spec
    key for key, value in six.iteritems(lines)
ValueError: max() arg is an empty sequence

Solutions

• Main issue is conceptual: unless the first release is marked as a bugfix release, a regular, non-major bug has nowhere to go until the first actual bugfix release.
  • This is arguably a sub-problem of #19, which is also the type of changelog I am encountering this bug within.
  • This could just be considered part and parcel of #19 insofar as "early/pre-1.0 releases should/could consider all issues as feature-like".
• Could implement a similar pre-seek/look-ahead here as we do for features, i.e. prefill the lines struct with not only major version but next minor version.
  • Plus: feels sensible/obvious
  • Minus: more complexity; still doesn't help with the conceptual issue of "hm wait I put this bug in my changelog but it's not appearing in my first 0.1.0 release". I.e. fixes the symptom but not the root problem
• Documentation/education only: inform users that if this is a problem for them, they should always stick some initial release before any bugs, or ensure pre-first-release items are explicitly marked feature-like in some fashion.
  • This is actually tempting since in my case I am translating a pre-Releases changelog where the first "entry" is simply "First public release" or similar. Put another way, this sort of "pre-release item" only really makes any sense if it's this sort of content-less "START OF TIME LOL" marker. Actual, real bugs can't exist before any releases are out.
  • However we should still put a useful error message around the symptomatic lines of code, so at least users know why it's erroring/unhappy.
• Following from thoughts there...perhaps make it so start-of-time situations where the struct looks the way it does here, trigger a "this is an implicit item, make it act feature-like instead of bug-like" behavior.
  • Plus: solves issue neatly, works well with conceptual notes above
  • Minus: means differing behavior at differing parts of the changelog, which isn't amazing.
  • Counterpoint: this is a very special/corner case, and we also already have some differing behavior stuff with the new-in-1.1 pre-major-release stuff, so there is precedent.

[bitprophet]

FTR went the route of making all bugs major bugs before a release; felt like only applying it to implicit bugs would a) be inconsistent and b) still cause explosions for anyone being silly with an explicit bug in this location. Better to just do it this way than have some "hey I am showing you an error but still not doing what you probably wanted" special exception.