You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could do with a nicer way of version numbers - currently we have to update our local version and remember to also update the sample version. When the update goes live we also have to remember to update the config files there.
I'm thinking we could automate this as long as we follow a certain set of rules. Given a version number like 1.0.1:
Each pull request to main increases the furthest-right number by one - 1.0.2, 1.0.3, and so on
When a Milestone is completed (or when we do a new release), the version number is set to the release number - release 3.0.3 would update 1.0.1 -> 3.0.3
We still need to factor dev into this, however. My thinking is that each merge to dev takes the current version of main and bumps the furthest-right number, finishing by appending a b to the end. If main is 1.0.1 then a new PR to dev becomes 1.0.2b, main is 3.1.7 then dev is 3.1.8b, etc
The text was updated successfully, but these errors were encountered:
We could do with a nicer way of version numbers - currently we have to update our local version and remember to also update the sample version. When the update goes live we also have to remember to update the config files there.
I'm thinking we could automate this as long as we follow a certain set of rules. Given a version number like 1.0.1:
main
increases the furthest-right number by one - 1.0.2, 1.0.3, and so onWe still need to factor
dev
into this, however. My thinking is that each merge todev
takes the current version ofmain
and bumps the furthest-right number, finishing by appending ab
to the end. Ifmain
is 1.0.1 then a new PR todev
becomes 1.0.2b,main
is 3.1.7 thendev
is 3.1.8b, etcThe text was updated successfully, but these errors were encountered: