Add ability to define RLS from which to detect changes

[miroslavpojer]

Background

The current version looks to the latest release Tag as a starting point for filtering Issues and commits.

• The latest Release is now used with the most recent date of release (created-at or published-at).

Feature

• Default:
  • When the user does not specify any value in the input field.
  • The latest tag will be used. ==> Today's behavior.
• Nondefault: The defined input version tag will be used from the tag.
  • Newly: Check for existence of from tag will be performed.

Example

• Tag 0.6.0, 0.6.1(latest-1), 0.6.2 (latest)
• Tag 0.7.0 should contain all changes
  • default: from 0.6.2
  • non-default: from 0.6.0 not from 0.6.2 (when input is 0.6.0)

[benedeki]

I am questioning this logic. Why would one include things, that were part of the previous release notes? Rationale?

[benedeki]

Unless a general, probably optional, logic, that if a higher order version changes, all the changes since the lower one are included 🤔
1.2.2 -> 1.3 = all RNS since 1.2.0
1.3 -> 2.0 = all RNs since 1.0

[dk1844]

I am questioning this logic. Why would one include things, that were part of the previous release notes? Rationale?

The user may want to select another start point for filtering

I think the key here is that the user may select another starting point.

In case of 0.7.0 release, a lot of issues/PR were filtered out as they were merged prior to the creation datetime of 0.6.2 while not being actually included in 0.6.2 at all. In this particular case, should this feature exist, the user may select 0.6.1 as the starting point to generate RNs from. (so 0.6.1..0.7.0 rather than 0.6.2..0.7.0).

Manual intervention is needed to tidy up, weed out things that do not fit, but it is much easier to remove extra generated content than to fill in missing items.