inverted-capital
commented
2 years ago I think we should adopt a customized version of semver. Semver can be matched with different operators, like ^2.3.1 to indicate that you are happy with any version changes that have the same major, but any minor or patch values can be greater than 3 and 1 respectively. So you can invest in a Request using ^2.3.1 or just LATEST if you agree with whatever updates QA lets through
Semver is major.minor.patch and our version should be:
- Major: Something material to the item has changed
- Minor: Extra definition as added, such that something passing the new version would definitely pass the previous version too. This is in contrast to relaxing constraints, where something passing the new version might not pass the previous version.
- Patch: if it is simply grammar, spelling, or other minor changes, increment the patch number
Hows that sound ?
Should we allow for Requests and Ideas to be changed inside of a Pool by the original author or force them to fork?
Think it's highly likely that things will come up after acceptance into the Pool that means edits are necessary. These changes should be QA'd, but if we force each change to fork we'll be left with a large number of very similar ideas cluttering up the Pool.
One argument would be that we'd let this happen, and let the market decide which is the best. But for some edits it may be very small, and so there isn't enough for the market to differentiate on.
Another argument would be that we allow an author to voluntarily remove a doc from a Pool. In which case it would equate to an edit. I.e remove file from pool, fork out-of-pool version, resubmit to QA.