I maintain a handful of open source projects on GitHub and have had a few questions about maintaining software like this, specifically around versioning and maintenance. I don't think there is a single "right" answer but the discussion might help others working on their own libraries.
I work on .NET libraries though would be interested in answers to these questions for any language/platform/package manager.
How often do you actually release new versions of your library?
This question is quite broad and by itself, doesn't seem particularly useful. What I mean though is like, if you have someone raise an issue and you patch it, do you immediately release a new version of the library? Do you wait an arbitrary amount of time before releasing? Do you try and queue up multiple changes together before releasing?
How do you manage pushing out releases of your library onto whatever package manager etc you use?
Again, kinda a broad question on the surface. I know various package managers would have CLI tools or might just read the "releases" or tags on GitHub. What I'm interested in here is the process of actually bumping a version number of your library and getting it out.
For example, I work with .NET and currently have the version number in a *.props file which is read during the build. This version is manually updated in an "update version" commit (eg. "Version 1.0 Released"). I then add a release to GitHub with the same version number and set it to create a tag with that same version number.
Now, I take the built package from the CI server (as it fires off a build when the tag is created) and I manually login to NuGet, uploading the package.
Now I know I could at least automate the pushing to NuGet but is that a good thing to do here? Should I even be letting certain CI builds just automatically push to NuGet? Should these be bumping their own "patch" version numbers? Would I be pushing out too many releases then?
This is probably the most important/curious question of the 3 that I have. Any thoughts on this stuff would be awesome.
How do you approach maintaining old versions of the code base, particularly when they are a major version behind?
I follow Semantic Versioning so I already considering breaking changes requiring a major version bump.
If someone is working on an older version of the library, do you go back and fork off the code base from that version and have it with the new fix? Do you just tell people to upgrade to your latest (major change) version which has it fixed? Is it something else in between?
When I have worked with open source products (eg. CMSs), they do normally maintain a few major versions back and patch with security updates. Do people do that with libraries too? Do you just maintain a "cutting edge" version of the library? Is this more a case of resources/time to be able to maintain a series of patch versions of older releases?
Top comments (4)
Pretty much release after each PR, which addresses one issue / new feature.
I just change the version inside my .csproj file and run
dotnet build -c Release. My .csproj is configured to build a nuget package automatically, which I'll then publish to NuGet usingdotnet nuget push(with my API key etc. added).I don't worry about old versions of the codebase...what's on master is what everyone should be working from. If not, they should pull/merge the diffs.
Thanks for responding!
With point 1, I would have thought that it may have felt like a lot of releases for small changes. I do see benefits in management of bugs etc (eg. using version 1.2.5 was fine but 1.2.6 is broken - you know exactly where the bug came from) but if you have a lot of changes happening, the versions would have gone up fast. Is this more a case of "stable" development where there isn't a whole lot happening every other day/week?
Ya, in my case, there aren't usually tons of bugs or features to tackle all-at-once. If that were the case then ya, I'd shoot for bundling a few of those into each release.
Managing a FLOSS project is tough enough without trying to support old versions. If someone else has a need for the 2.x version, let them maintain it.