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

Recommended Snapshot Release Numbering #200

Closed
marecabo opened this issue Feb 10, 2024 · 3 comments
Closed

Recommended Snapshot Release Numbering #200

marecabo opened this issue Feb 10, 2024 · 3 comments

Comments

@marecabo
Copy link
Collaborator

Hello @polettif,

do you have any ideas on how to do a snapshot versions for pt2matsim, given its year.month versioning scheme? I do not know, how to number a snapshot release, if I do not know yet, when that snapshot release becomes a full release.

Background
@mrieser and me are working on enabling MATSim for dealing with OSM turn restrictions (matsim-org/matsim-libs#2829), which requires MATSim 16.0-PR2855 version. The branch disallowed-next-links contains the code for generating the required data for considering turn restrictions in routing.
If possible, I would prefer to have some kind of PR snapshot releases, like MATSim has, to share and try out these newer features with the MATSim community.

Looking forward to your thoughts.

@polettif
Copy link
Contributor

Nice to hear that you're working on these improvements!

I'm not quite sure, how to use snapshots correctly with the year.month scheme. Is there a reason against using 24.2-SNAPSHOT while working on it and if some months pass by just release it with the actual date? It is just a snapshot after all. Also, I don't know much about automatic snapshot releases (with commit hooks or whatever), all releases have been created manually so far.

To be honest, I didn't put a lot of thought into the versioning scheme back then, year.month just seemed fine with the only somewhat regular release schedule. Also, I didn't want to think too much about what constitutes a minor or major update. Maybe linking the major release to the base MATSim version would've been better but I'm not sure MATSim's versioning was that straightforward back then.

@marecabo
Copy link
Collaborator Author

marecabo commented Apr 20, 2024

Is there a reason against using 24.2-SNAPSHOT while working on it and if some months pass by just release it with the actual date?

As we do not have planned releases, I'm fine with that. In the case, where we want to do two releases in a single month, we have to think about it again, or append .1, or just wait.

My only recommendation would be, that after doing a release (e.g., 24.4), the next commit should set the version to the next snapshot version (e.g., 24.5-SNAPSHOT) in the pom.xml, so it is clear from looking at the repository history, which revision was actually released as 24.4.

@polettif
Copy link
Contributor

As we do not have planned releases, I'm fine with that. In the case, where we want to do two releases in a single month, we have to think about it again, or append .1, or just wait.

Yes, I'd suggest simply adding .1 if another release within a month is necessary (happened already with 20.11.1).

My only recommendation would be, that after doing a release (e.g., 24.4), the next commit should set the version to the next snapshot version (e.g., 24.5-SNAPSHOT) in the pom.xml, so it is clear from looking at the repository history, which revision was actually released as 24.4.

Sounds good to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants