Closed jonassmedegaard closed 3 years ago
Thanks for your interest in Marpa.
There is no public versioning, so what you see is for my own use, and I'm glad to hear it seems careful. I did have in mind that I'd need to go public someday, which explains some of the care I took.
Do you have recommendations for tags, etc? One reason I didn't create tags was that, thinking of the day I created a public versioning, I didn't want to paint myself into a corner.
Not sure if you are asking generally about versioning scheme or something more specific...
I would suggest to prefix version tags with "v" and use semantic versioning - i.e. always use 3 parts (major, minor. revision), bumping revision for each release with no ABI change, or bump minor and reset revision for backwards-compatible ABI changes like feature additions, or bump major and reset minor + revision for backwards-incompatible changes.
I would at first cheat a bit and use major version 0 as being "any ABI" - i.e. instead of not making formal tagged releases as all I would generously tag but indicate that there is no promise about ABI breakage by staying below major release 1. That way the progress of the codebase gets tracked while it matures, and when you realize at some point that it has matured you can simply re-release as version 1.0.0. Or if you never stabilize the ABI then just stay below 1.0.0 forever.
Since you are already track library API, I suggest using major version of API as minor version of library releases - i.e. now that code is at API 8.6.2 I suggest tagging that as v0.8.0
and move on from there using semantic versioning methodology for the release versions.
Oh - I just realized that you have already made 3 tags using 7 as major version.
If you want casual versioning at first, then I suggest simply ignoring those 3 tags and do as suggested above: make a v0.8.0
release and move on from there. If you then at some point was to treat your library as stable then you can bump straight to major version 8 (or whatever major version your API has become).
I was asking the question in both senses. I was asking for general guidelines, but I also planned to ask you what you thought about specific version tags.
Speaking of which, I think it may be time for v1.0.0. Libmarpa has been stable for some time and an essentially identical version has seen widespread use as the basis of Marpa::R2. This suggests to me I must at this point decide to be one of those shy folks who never does a v1.0.0, or else take the plunge.
Also, I note you have been associated with Debian. Is your interest in Marpa at this point at all related to this?
Back to v1.0.0. Either way, I will want to think this over. It's a major plunge on a project that is well over a decade old. This means that, while in one sense it is a very simple change, I will not resolve this issue quickly.
I've been away from this repo for a while, and have started looking into it, making sure I can build it on my environment, etc.
One solution is really simple. Create a v8.6.2 tag, and announce that v8.6.2 is the first pubic release. @jonassmedegaard -- any comment?
Releasing/tagging what you got now as v8.6.2
was what I had in mind when I filed this issue. That's the simplest sensible action I can think of doing now - but does not take into account shyness...
Also, I note you have been associated with Debian. Is your interest in Marpa at this point at all related to this?
Indeed, I am a Debian developer. In 2014 I packaged Marpa::R2
, then a dependency of Catmandu
- but by the time I succeeded getting Marpa::R2
into Debian, Catmandu
changed to use Parser::MGC
instead and I lost interest in Marpa::R2.
Fast-forward 7 years, and my work authoring App::licensecheck
has got me curious about faster-than-regex parsing and I rediscovered Marpa and wanted to at least modernize the packaging in Debian, even if possibly I fail at wrapping my head around using it myself.
In Debian shared libraries are preferably built separately from wrappers, and also we prefer tracking the true source - that's the reasons I ended at this git repo - hoping to be able to tie this codebase and the Marpa::R2 perl codebase together.
I'm doing a full test with Marpa::R2, prior to creating the tag. This will involve running Marpa::R2 using a libmarpa library, a process which I documented in https://github.com/jeffreykegler/Marpa--R2/blob/master/cpan/engine/STATIC and https://github.com/jeffreykegler/Marpa--R2/blob/master/cpan/engine/SHARED . This sounds like it's of interest to you, and in the process I will wind up testing and fixing typos (I hope no worse) in these documents. I'm rusty at all this, so this will take a few days.
I think you understand, because I expect folks who want something in Debian just say, "Why not copy the repo and be done with it?" and if one is careful, things are not that simple.
I do understand, and I appreciiate your work.
Please do tell if you want me to test or proof-read something. Or even better: Simply release as soon as you think it is ready yourself - and then be prepared to make another bugfix release in case I manage to spot something too flawed that it cannot collect dust until next time you get around to make a feature release :-)
I completed the tests, and have added the tag https://github.com/jeffreykegler/libmarpa/releases/tag/v8.6.2 . This is the first official release.
@jonassmedegaard If all looks good to you, let me know and I will close this issue.
For followup discussion, you might consider our IRC channel: #marpa on idiosyncrat@irc.libera.chat .
If it's an issue, of course, the best place for it is as another Github issue. Thanks!
Since I haven't heard any negative feedback since my last comment, I am closing this issue for the reasons given in that comment. Thanks @jonassmedegaard for bringing it to my attention.
This library seems to be carefully versioned (great!) yet very few releases have been tagged.
Please tag releases.