search

matsim-org / pt2matsim

Package to create a multi-modal MATSim network and schedule from public transit data (GTFS or HAFAS) and an OSM map of the area.
http://www.ivt.ethz.ch/publikationen/studenten/530.html
GNU General Public License v2.0
48 stars 66 forks source link

Recommended Snapshot Release Numbering #200

Closed marecabo closed 4 months ago

marecabo commented 7 months ago

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 (https://github.com/matsim-org/matsim-libs/issues/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 commented 7 months ago

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 commented 4 months ago

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 commented 4 months ago

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.