I admit the title "You Should Use Releases on GitHub" draw me in as it (no offence intended) smacks a little of arrogance - and that puzzles me on dev.to when I see it (which I do from time to time).
For my part, thanks, it's a nice reminder that releases are an option and I like that.
What if overlooks (and this relates to the impression the title gave me) is that rolling-release model of development is very valid and has some enormous traction in the world of FOSS, Entire Linux distros are based on it. And many a FOSS project as well. Many have formal releases and version numbers. But others, work quite well, simply with one master branch, development running on side branches and merged into master when tested and ready for the wild.
Such merges can increment a version number or not, remaining identified by the date alone.
Of course, where end user support, or customer support begins to be a significant issue, release and version numbers facilitate a few important things indeed (helping people identify which version they are using when looking for support for example and grouping these merges into fewer, larger, more significant updates). In the case of a rolling-release product for example there is often no end user support that doesn't start with "Have you pulled the latest release?" ;-).
But methinks one reason projects opt for that is that the rate of change is high, and another is that the hands on deck are few (you rightly identified it's work, releasing a product and if there are barely enough hands on deck to triage issues and develop the software, well, something gives ...). Both of these of course are more common early in the life cycle of any piece of software, and as it (and if) gains popularity and resourcing, to be sure, wonderful things like release management and documentation either pop up or take on more shine etc ...
First let me say you have some very valid points and I do agree with you, but perhaps I am very biased, being brought up on open source software on a Linux foundation, so I often expect the rolling-release model you describe, which might be a mistake on my side.
But let me add some perspective.
I put open source software repositories into two major groups.
End-user software, like clients etc. software I use often as part of my toolbox etc.
Libraries, components etc, software that are used in my different stacks
For the first part a rigid versioning scheme is not required from my point of view, it is nice. But as you state it, a main branch with transparent updates works just fine.
As for the other part, I often need to express/state my dependencies very clearly and often in dependency description files which can be resolved by my toolchain for easy installation etc.
Since modern software is very much comprised if dependencies, as opposed to writing everything yourself and since we have resolved the challenges of distribution and sharing, we are building software which is relying heavily on external components/dependencies - this brings forward a lot of challenges.
Personally I spend a little time on keeping my project dependencies up to date and all I request is for the developers/maintainers to lend me a hand, when they make releases - but I can make it even without these extra efforts. My worries are mostly centered about: toolchain attacks and becoming the weakest link in the chain, so I have an incentive to keep my projects updated.
From a professional perspective I am a bit more concerned and leaning more towards a more rigid regime and that might be what is shining through in my post.
Many companies today is using and building on open source software, which is great. But with that comes the requirements of compliance, licensing etc.
I am currently evaluating tools from companies like:
Which could help me in mapping out use of open source software, use of licenses etc.
These companies and their tools are dedicated towards this particular problem area and they have the resources to poll all the relevant repositories and might not be dependent on for example release notifications, which I see as more of an event based schema, compared to just polling all known repositories.
These tools however do not come cheap and small shops do not necessarily have the resources to poll all of the dependencies like these dedicated companies, so instead of polling all of this information, it might prove more interesting to use an event based flow, like release announcements.
As for the rate of updates/releases, that is a different challenge. I just signed up to following react-admin, boy these people are active. Which is good and it keeps us on our toes, luckily they use GitHub releases which makes it easier for us to keep up.
As I see it, the problem of keeping is not going to go away. Personally I am not so concerned for my small side-projects, professionally I believe this will only become a more inevitable challenge, that in the end we might have to though money after.
I have a final question to you, just as a thought experiment:
Not at all. Thank you for a solid article and friendly response to feedback.
As to your final question I'd just tone down the hype a little. You see I find hype interesting it sort of evolved in an era of media (latter half of the 20th century) as a marketing tool, to grab peoples attention. By hype, I refer to exaggeration, superlatives, imperatives and such used in headlines and announcements I guess.
Alas, IMHO, the world has evolved a little. We went through a fascinating period in the evolution of the World Wide Web, that many of now think of the "upworthy" era. Upworthy was a flash int he pan, huge phenomenon on-line, flooding information and sharing channels. But they had this incessant habit of hyping up all their headlines and we saw a rapid response with downworthy browser addons that would strip the hype from web pages:
And I guess in my view the professional world has reacted by holding hyperbole in mild disdain in technical articles since.
Yours is not even bad. Better hype would have been "You must use releases on GitHub" or "You'd be crazy not to use releases on Github" or "No serious coder would ever fail to use releases on Github". It's actually quite fin playing with spin and hype.
But if I had written or reviewed (as an editor prior to publishing) your article I guess I'd have opted for a softer title ... like "Using GitHub Releases Effectively" or "Easy Release Management using GitHub Releases" etc.
I guess descriptive rather than imperative.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I admit the title "You Should Use Releases on GitHub" draw me in as it (no offence intended) smacks a little of arrogance - and that puzzles me on dev.to when I see it (which I do from time to time).
For my part, thanks, it's a nice reminder that releases are an option and I like that.
What if overlooks (and this relates to the impression the title gave me) is that rolling-release model of development is very valid and has some enormous traction in the world of FOSS, Entire Linux distros are based on it. And many a FOSS project as well. Many have formal releases and version numbers. But others, work quite well, simply with one master branch, development running on side branches and merged into master when tested and ready for the wild.
Such merges can increment a version number or not, remaining identified by the date alone.
Of course, where end user support, or customer support begins to be a significant issue, release and version numbers facilitate a few important things indeed (helping people identify which version they are using when looking for support for example and grouping these merges into fewer, larger, more significant updates). In the case of a rolling-release product for example there is often no end user support that doesn't start with "Have you pulled the latest release?" ;-).
But methinks one reason projects opt for that is that the rate of change is high, and another is that the hands on deck are few (you rightly identified it's work, releasing a product and if there are barely enough hands on deck to triage issues and develop the software, well, something gives ...). Both of these of course are more common early in the life cycle of any piece of software, and as it (and if) gains popularity and resourcing, to be sure, wonderful things like release management and documentation either pop up or take on more shine etc ...
Hi @bernd
Thanks for you very extensive comment.
First let me say you have some very valid points and I do agree with you, but perhaps I am very biased, being brought up on open source software on a Linux foundation, so I often expect the rolling-release model you describe, which might be a mistake on my side.
But let me add some perspective.
I put open source software repositories into two major groups.
For the first part a rigid versioning scheme is not required from my point of view, it is nice. But as you state it, a main branch with transparent updates works just fine.
As for the other part, I often need to express/state my dependencies very clearly and often in dependency description files which can be resolved by my toolchain for easy installation etc.
Since modern software is very much comprised if dependencies, as opposed to writing everything yourself and since we have resolved the challenges of distribution and sharing, we are building software which is relying heavily on external components/dependencies - this brings forward a lot of challenges.
Personally I spend a little time on keeping my project dependencies up to date and all I request is for the developers/maintainers to lend me a hand, when they make releases - but I can make it even without these extra efforts. My worries are mostly centered about: toolchain attacks and becoming the weakest link in the chain, so I have an incentive to keep my projects updated.
From a professional perspective I am a bit more concerned and leaning more towards a more rigid regime and that might be what is shining through in my post.
Many companies today is using and building on open source software, which is great. But with that comes the requirements of compliance, licensing etc.
I am currently evaluating tools from companies like:
Which could help me in mapping out use of open source software, use of licenses etc.
These companies and their tools are dedicated towards this particular problem area and they have the resources to poll all the relevant repositories and might not be dependent on for example release notifications, which I see as more of an event based schema, compared to just polling all known repositories.
These tools however do not come cheap and small shops do not necessarily have the resources to poll all of the dependencies like these dedicated companies, so instead of polling all of this information, it might prove more interesting to use an event based flow, like release announcements.
As for the rate of updates/releases, that is a different challenge. I just signed up to following react-admin, boy these people are active. Which is good and it keeps us on our toes, luckily they use GitHub releases which makes it easier for us to keep up.
As I see it, the problem of keeping is not going to go away. Personally I am not so concerned for my small side-projects, professionally I believe this will only become a more inevitable challenge, that in the end we might have to though money after.
I have a final question to you, just as a thought experiment:
Not at all. Thank you for a solid article and friendly response to feedback.
As to your final question I'd just tone down the hype a little. You see I find hype interesting it sort of evolved in an era of media (latter half of the 20th century) as a marketing tool, to grab peoples attention. By hype, I refer to exaggeration, superlatives, imperatives and such used in headlines and announcements I guess.
Alas, IMHO, the world has evolved a little. We went through a fascinating period in the evolution of the World Wide Web, that many of now think of the "upworthy" era. Upworthy was a flash int he pan, huge phenomenon on-line, flooding information and sharing channels. But they had this incessant habit of hyping up all their headlines and we saw a rapid response with downworthy browser addons that would strip the hype from web pages:
downworthy.snipe.net/
And I guess in my view the professional world has reacted by holding hyperbole in mild disdain in technical articles since.
Yours is not even bad. Better hype would have been "You must use releases on GitHub" or "You'd be crazy not to use releases on Github" or "No serious coder would ever fail to use releases on Github". It's actually quite fin playing with spin and hype.
But if I had written or reviewed (as an editor prior to publishing) your article I guess I'd have opted for a softer title ... like "Using GitHub Releases Effectively" or "Easy Release Management using GitHub Releases" etc.
I guess descriptive rather than imperative.