About the current versioning policy with "next" #1780
Comments
|
👍 @pat-s I'm working on a project with ca. 100 DEVs and using Drone massively for ca. 5 years. The license fees did not match the budget anymore so we looked for alternatives. From the evaluation process I led, I can tell you, no one knew Woodpecker CI. That said, when I did my two recent contributions, I realized how many goodies are present and not documented nor released. That's a shame and I really wish more often releases of Woodpecker and shipping what's there. Also, with more often releases, you will get more feedback. That's a common benefit from short release cycles, you catch even the "reluctant" people who prefer waiting until a 1.0.0 version is hardened. Personally, I don't mind, if you continue 0.16.x or jump straight to 1.0.0. After all, the core features of Woodpecker already are the equivalent of a 1.0 version == it's fully functional. Every issue I saw in the Github project backlog for 1.0.0 - seems to me like another cherry on top ;) Thank you for all your effort of making Woodpecker great 👍 |
|
Imho we should finish with #567 before 1.0 to have single breaking change in pipeline yaml format |
|
Well the issue list is getting smaler and i'm currently focusted on bugfixing plus clean up low hanging fruites that do block 1.0.0 Beside the group vs depend-on dessision for steps ... i would say all big breaking changes are mostly done |
|
And without a good reason i wont add anythin to the baglock ... more i move things into v1.1.0 if they are non breaking & blocking |
That sounds great. |
|
You can take a look at the 1.0.0 milestone (which also contains PRs) |
|
Waterfall vs Agile 😄 @pat-s, @nitram509, 99% agree with you.
Suppose current What if we leave semantic versioning as currently is, but introduce calendar versioning for the |
|
We already tag next-commitid based to be able to pin a specific next version ... Open issues for v1.0.0 are now down to 27 ... so it never looked that promising ;) I encourage all here to just hve a look at the issues labeld with docs ... that will bring down the number and is easy to address |
That's just how the game works. Major releases are (in my vision) just an indicator for breaking changes, i.e. action is required by the users. It just says "read the changelog carefully and don't blindly update". Yes, one certainly does not want to have such release every few weeks - but this is also not what I am aiming for. There's a sweet spot between not releasing a "usable" version for over a year and the former. I don't mind a software running on 15.12.x - as long as the release and changelog make sense and do "their job". Also I am fully aware that the above is slightly subjective - though I would also argue it's the implicit default which most people agreed on in (public) software development.
Being a maintainer myself and applying semver, I don't. With my main point being that it's hard to follow the changes in I am aware that I can't change this and that the current philosophy is different here but I can at least bring the topic up for discussion and express my thoughts.
I appreciate everyone's work but 27 doesn't sound like a "small" number 🙃 And phrased in another way: most of these are probably "not breaking" and more like "small enhancements"? (haven't gone through the list though). Also I hope that after 1.0.0, whenever it will happen, there won't be another "next" but maybe a "normal" release cycle of a few months with a curated changelog 💟 . Last I'd like to express my gratitude with the project, I like it a lot (the idea, the motivation, the product) and I/we are also about to start sponsoring it ❤️ . I don't want to sound mainly negative in this issue, my goal is just to bring up the discussion and maybe start a thought process through it to make something better. |
|
Well what we could do is to decide on some guidelines like if we hit max 3 breaking changes and/or 5features ... a release should be prepaired |
You don't need to support old major versions. Semver does not require that. |
|
First of all, I also think this is a great project with a lot of potential and you have my many thanks for its existence. 👍 TLDR; I agree with the sentiments of @pat-s @nitram509 and @zc-devs they shared above with regards to using semver. Breaking changes in a non-major version is fine if the major version is zero. I'd like to share some experiences and thoughts, my apologies for being long-winded: First use experience Some time ago, I started using Woodpecker instead of Drone. Fair warning, I'm gonna be brutally honest here. The experience was... horrible. Sorry, but it was. Not trying to be negative here but I got to be honest for clarity's sake. 😃 Setting up Drone cost me about one hour with a hello world pipeline building successfully. When I learned about Woodpecker CI, I wanted to support the pure FOSS project and switched. Looking at the site and docs, I started off with the I spent quite some time trying to get everything setup. Docs were unclear, communication between server and agent kept breaking for unknown reasons & with unclear error messages, pipelines were unreliable. I looked through the docs, the Github issues, outstanding PRs and even the code for hints to my problems. Solution Out of sheer desperation I tried the "next" version which I would normally not do since I don't run development branches in production normally. Though I still had a number of issues, mainly in a lack of good quick start documentation, stuff magically started working. On top of that, I suddenly had a bunch of features that I missed. It still took way more time to setup properly than with Drone, but if I'd started off with "next" instead of the My conclusions / suggestions:
On semver In semver, the MAJOR version number does indeed signify breaking changes. However, the zero (0) major version is special. It signifies that "we're in active development towards a In other words, breaking changes before you release a Like @runephilosof-karnovgroup stated, you don't need to support older versions. It is up to the admin to keep up-to-date with releases. If there's a bug in an older version, you fix it in a newer version. That's the whole point. Again, my apologies for the long-winded post here... it comes from good intentions. 😄 |
|
In regards to support... Imagine... You are on v1.11.2 (latest v1). Yesterday version 2.0.0 is released with breaking changes, changelog and all this stuff. Today some critical CVE has been discovered and fixed/released in v2.0.1 and won't be backported to v1 (right?). How do you feell? What are you going to do? *you - is not particular person, but who says And as of today developers still support previous release (even though it's useless in my opinion) ❤️ Hope, they will in the future after v1. |
|
CVEs are tryed to be backported at least one version ... so to say v0.15 would get it in this context |
|
My comment with regards to supporting previous releases was mostly geared towards supporting 2,3 or even more older releases. Supporting latest-1 is fine by me. |
Well, if I imagine being on Woodpecker v1, I would obviously hope for getting this fix backported. That said, the world is not black and white. I mean setting a clear message/guideline, that older versions are not further supported, could still be the easier choice for the maintainers of Woodpecker. On-Top, on a "per use case", a really critical CVE (thinking of ssl heartbleed, or log4j, etc.) still can be an exception of the mentioned rule and thus backported. Just my 2cent ;) |
|
@zc-devs wrote:
Suppose being on b1787f8 (next) and then #1743 is merged containing a breaking change. Even with no backporting, I still think it is an improvement over the current state.
So v0.15 already being treated as v1.x. Releasing next as v2.x, would mean that the next breaking change would make v1.x unsupported. Luckily, this is an open source project, so if the community backports an issue to an older version, there is a somewhat high probability that it will get released after all. @mvdkleijn wrote:
They also write https://semver.org/#how-do-i-know-when-to-release-100
|
|
This discussion got a bit off-topic and more into "backporting and supporting multiple versions". My initial proposal was mainly focused on the long developing time of "next"/1.0.0 and that, at some point, everything was just added to "next" without a clear idea when there will be release or a "stop" for new features. Not sure if this issue helped but now there is a shortlisted milestone and already a changelog documentation (WIP) and some features have been moved to a 1.1.0 milestone. For "professional" use this is a good thing and the main point I wanted to address :) Looking forward having a "proper" 1.0.0 release soon followed by "normal" feature releases coming in reasonable time frames :) Thanks @anbraten @6543 and everybody else doing great work. |
|
to @runephilosof-karnovgroup 's backport concerns ... as long as somebody do provide a working patch we can release, I dont mind to let it be released even for our v0.14 e.g. non maintained branches ... it's just that this is not the woodpecker-maintainers response in that regard ... |
|
... as long as the pipeline to release things does work or can be fixed easily for that branch |
When I said that, I thought about backend for mobile applications. But I've found beautiful example here. Support is going at next level ;) |
|
Further reasons for releasing more often... Less issuesAs a new user, I discovered a number of issues which took me a long time to research and fix. And in multiple cases I opened github issues or asked for help on the discord channel. In almost all cases the solution was "have a look at vNext". There are many new features and squashed bugs in vNext. If you release more often, you'll have fewer support requests. That is because most users use the latest stable version - so even if the fix is in "vNext", they won't know (as they are waiting for the next stable). More usersA related point is that since most users only use the latest stable, they have no idea just how advanced woodpecker is - they are judging it based on the latest stable, not vNext. It would attract more users if the latest goodies weren't hidden away for who knows how long. (And to echo what others have said above: the project is much appreciated, and some of the fixes and features in the |
|
As written before we all agree on this. Pleas hold your horses a bit. We will release |
✋ 🐴 |
|
1.0 got release and the idea is to release more often now if there are new features / fixes. |
Clear and concise description of the problem
The current "next" version is in fact a new major release which is in "rolling" development for a long time now.
Reading the roadmap in #869 let's one assume that there won't be an "official" release soon assuming all points listed there must be met.
This fact combined with the unclear state on this topic gives the project a somewhat "unprofessional" touch and also comes with versioning issues for admins. I.e. admins must work with sha checkouts based on commits and it is hard to get an easy changelog about recent changes.
Additional confusion comes in with the "old" 0.15.x releases which let many people start with this version first. However, people often face a lot of missing features and they get redirected to "next" then. Yet to upgrade they need to change many things, both users and admins, to compl
Given that so many people are on "next" meanwhile and "next" seems to be usable for many - agnostic from the backend - I would like to discuss whether the versioning approach could be rethought.
I am well aware that not everything is working perfectly yet but I don't think that users always expect an 1.0.0 version to be "fully stable" and "finished" in all areas.
Suggested solution
Release a 1.0.0 version and continue with a semantic versioning release policy for upcoming changes. This makes it a lot easier to follow development for admins and allows to have a "clean" changelog. Especially changes like #1765 which might break usability for specific OS might get unnoticed in the current versioning approach.
Alternative
No response
Additional context
No response
Validations
nextversion already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]The text was updated successfully, but these errors were encountered: