-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[proposal] Milestones for Versioning #365
Comments
Agree for versioning, docker image would also benefit from some kind of stability, apart from |
Actually, I see that tags are already created. I'll check if I can include them in docker hub. Disregard my comment about branches, seems it's not a requirement, just an option. |
@simonnagl, I like your proposal. My unofficial plan at this phase was to release every about 2-3 weeks. This is required mainly due to bugs (even the v1.1.0 release has significant bugs - the dashboard of v1.1.0 does not work on mobile browsers) or key new features. My cause with netdata is to prove that performance monitoring can be done with high frequency data collection (per second) and scaled out efficiently, with just minimal centralized functions. To deliver this, I should work in areas like optimization of the database, snapshots, registry, annotations. I now understand that also health monitoring (alarms, etc) is a core function that should be embedded in netdata. I am thrilled that if netdata can deliver on this promise (scale out), it may become an open, global monitoring system, free for everyone. Since minimal centralized functions will be needed, this seems feasible - the cost for the centralized functions can be insignificant, or even covered with donations by companies that use netdata. Of course this will not prevent anyone from having his/her own installation of the centralized functions. At the same time I understand that the success of netdata depends on the availability of data collectors, its packaging, new visualization techniques, dashboard editors, documentation. I even experimented a bit with blogging when I wrote a few of the pages found at the wiki (DDoS protection monitoring, You should install QoS on all your servers, etc). Future blogs could be "Monitoring Linux containers effectively", "Get to know your mysql/postgress/X database server", etc, Such blogs/articles spread the word, expand the user base and attract developers willing to contribute. A lot of people (like you guys) have helped netdata a lot during the last month. Actually I am impressed by the wide and quick adoption of netdata. However netdata needs a bigger developer base to commit on the delivery of features. Until we reach that point, It would be probably better to just set the beat: release once per month, for the following months, increasing the minor version number: 1.2, 1.3, 1.4, - or even the May release will be 1.5, December's 1.12, then on Jan 2017 we will go to 2.1 and so on. If we have such a beat, we could announce it, use the issue tracker assignments to let everyone know who is responsible for an issue and developers can grab feature requests or bugs and commit to deliver them by one of the following releases. I will do the same. Of course I am open to any other ideas too... |
@philwhineray @glensc @mcnewton @alonbl @fredericopissarra have a look. Your opinion matters. |
I do not know if releasing in a fixed beat is a good idea.
I think also without having a big developer base yet, netdata should get some rules:
|
I don't think introduction of bugs is likely to be particularly related to the organisation of releases; they will relate to the rate of change. Bugs will only be squashed by testing, good review or lack of changes. With git, everything is a branch and I would expect pull requests to be accepted when they are ready (whatever that means), not before. I agree that something (wiki page or bug) to list high priority contributions would be useful. More so than a which roadmap which might tell you to expect something but doesn't guarantee anyone does the work and might have the effect of discouraging people from contributing changes they find useful enough to create but are not "on the list". Since the code is still young and moving quite fast I think a short, possibly semi-fixed cycle will work well, so that people know that if they try to contribute some code and it is "not ready yet", then they will not have to wait months to see it included in a release. I understand the desire to provide some certainty but I think when a project is made up of volunteers, then certainty is mostly an illusion. I can point to myself and how my time has vanished recently but I occasionally get back a few hours or a day or so. Any attempt to work to a roadmap is doomed to failure for me. If you want something more formal but that caters for a wide range of contributors, then a bug or page tracking what is being worked on and expected to go into the next release (signed off or nearly signed off) and possibly the one after that (code exists / someone is working on it) would provide some idea... but as usual it requires someone to put effort into curating the information. If there are enough testers, take the linux kernel idea of having a "next" branch which tracks pull requests mooted for inclusion so it is all in one place ahead of a release. |
I'd also skip fixed release dates in favor of actual milestones. As a good example (in my opinion), take look at the golang/go repo. PR's and feature requests are sorted in explicit versions, and they may or may not be included in a version - depends on stability.
The reason for explicit tags (and not time based tags) is that they specify what kind of changes happen in APIs. If people write software which might depend on some standard output available in 1.1, they can be sure that the change to 1.2 might incur some minor changes, and that the change to 2.0 is a complete rewrite of existing interfaces. Think of versions as impact: [major].[minor].[patch]. So when you're changing 1.0.123 to 1.0.134 it's a bugfix release, 1.0 to 1.1 however is change in functionality. A time based approach doesn't consider these factors. Also: bugfix/patch releases are mostly for posterity - I usually just put a timestamp as the patch version, any sequence will do. Bump minor version with change of functionality that might break existing clients/compatibility. |
indeed i'm impressed the netdata quick adaption, finally those 700+ forks have fired back as issues, and pull requests (i've subscribed to this project all activity). about releases, i wouldn't use strict release plans, just release when you have time and feel the changes depart from last release that release is necessary to have documentation and last release matching. |
Just to be clear, I'm not advocating tags based on timestamps, just that Versions would be incremented along the lines of http://semver.org/ and At some point the rate of change will likely tail off and then it makes On 4 May 2016 at 08:38, Tit Petric notifications@github.com wrote:
|
ok. I also agree that semver.org compatibility is better. |
You guys convinced me that maby having features on fixed milestones is a bad idea. For using semver we should once define what is in our current public API. Configuration? REST? PLUGIN interface? I would like to contribute to netdata documentation too. Currently (git wiki) it is not possible for everyone because pull requests do not work for it. |
What would be nice is to use jekyll or something else to publish it on github pages. We could have charts from the demo installations into it, which would be... wow! We could also have analytics to know what the users use... A simpler solution could be a simple clone of the wiki to put it in a |
Quite. As @ktsaou says it is possible to clone a wiki, which means one could use old-fashioned patches... Meantime, @simonnagl , if you apply to join the project I expect it will be accepted. You can be added to the netdata team which will allow write access to the wiki direct, which should be fine: I think they were locked due to vandalism, not because we want to stop edits more generally. |
On 05.05.2016 03:20, Costa Tsaousis wrote:
or as wiki is git repo, create separate project that mirrors to wiki's git https://github.com/firehol/netdata-doc.git@master -> glen |
@philwhineray Thank you for the invitation. Nevertheless I think it is needed that everybody can contribute to the wiki in a save way. I know about old fashiond patches but I like the idea of @glensc more, if this is possible. |
@simonnagl you mean my idea of having git repo "netdata-doc" which on master branch push updates wiki? i think that can be accomplished with Web Hook that posts to some hosted server which does the git pull from netdata-doc and push -f on netdata.wiki, but that means nobody should edit via native github wiki interface, two way merge ends up as a mess. if the documentation is structured as documentation format, it's likely better to use https://readthedocs.org/ instead. |
Yes, I did mean that. readthedocs.org looks even better. I will open a new issue to discuss where to document what. |
Just as an option, I've used |
Currently I like the idea of jekyll sites most.
|
I like to make some proposals.
Grouping enhancements and bugs in milestones will give the following benefits.
Above when does not mean a time, but it means in the near feature, in the next release...
The text was updated successfully, but these errors were encountered: