Lots of information to digest and respond to, much of which I cannot due to time limitations.
I suggest everyone print out a copy of C4 and don't bring judge it with your preconceptions. Give it an opportunity to let it speak for itself. Go over every point in it and once you understand it. You can adapt accordingly. Matt said: This is probably obvious, but if the PR being merged into the stabilization branch/fork must also be applied the bleeding edge master. Stewart says: Correct Matt said: Can't we assume any scripting environment would have to do a "git clone" against a target URL denoting a stable release? If so, there's not much of a difference between a "git clone VERSION-SLUG" vs "git clone nupic; git checkout VERSION-SLUG". Is this really an issue, or am I missing your point? Stewart says: We can assume nothing. Many package manager community members prefer downloading the raw .gzip file. have a look at all the different package managers they can get quite complex yet all of them support the raw .gzip / .zip. It's best to keep the lowest common denominator the .gzip. > * The branching model encourages too many stabilizations at the wrong > time or even worse stabilization by date releases. Matt said: I don't see how it does. Are you suggesting that it is easier to branch, therefore we'll be more likely to create release branches? So the additional overhead of forked releases will prevent gratuitous releases? If so, I don't believe we'll allow that to happen. Releases should happen, as you said, when it "feels right", not because it's convenient. Whether we branch or fork makes no difference. Stewart says: stabilization should organically happen and be done by anyone anywhere. The project then takes on its own life, feel and own character. It develops its own community of 'blue-ish' people. What I'm worried about is the corporate 'lets stabilize at these times of the year' idea. This shouldn't happen. Open source projects have their own rythm and feel. You'll know when it's time to stabilize. Matt said: When you say "rolling release", what exactly do you mean? I understand that there can be no feature additions within the stability branch, only bugfixes. Let's use a concrete theoretical example. This is what I *think* you mean, so please correct me: - NuPIC is at v1.0 - devs add bug fixes and new features on master - devs decide it's time to release - a stability (branch|fork) is created as v1.1 - a bug is reported against v1.1 - devs work to correct and patch bug on v1.1 - stability branch stays v1.1 - if bug is severe enough, fix is applied to master as well (without waiting for a merge from the official release into master) - v1.1 is declared stable! - v1.1 is tagged as official and merged into master >From what I imagine above, we would throw out the PATCH in the semantive versioning scheme of vMAJOR.MINOR.PATCH. All MINOR releases would simply be new features and bugfixes. MAJOR releases would break the API. Right? Stewart says: If a rolling release is chosen then the "Evolution of Public Contracts" section of the C4 must be _strictly_ followed. In a rolling release there are no versions/stabilization forks or branches. The development codebase will work for legacy projects dependent on nupic as well as new projects. I recall having a deep discussion over many emails with Pieter Hintjens (C4 creator) about this and he regrets not taking the rolling release earlier on in zeromq. But zeromq inertia kept the stability forks around. I have seen rolling releases work exceptionally well. Entire operating systems use it to great effect, but that effect can only be as good as the maintainers adhering to the "Evolution of Public Contracts" section. Matt said: You don't think we should at least establish this stabilization process beforehand? I think it would be useful to start off creating v0.1, v0.2 "beta" releases now, building up towards something we all agree should be flagged as v1.0. Do you think we're getting ahead of ourselves by having this discussion too early? Would you rather we dedicate our resources to working on those issues you describe above before we continue this carry on this dialogue? Numenta has received a few independent inquiries about commercial licenses for NuPIC. So the demand for an "official" API could be closer than we think. Stewart said: We need to discuss this, its important in my view. You can still do commercial licenses on a rolling release _as long as public contracts are kept rock solid_. Maybe you could stabilize just for commercial licenses, that way you can earn more by selling new licenses / upgrade licenses. (Though I believe commercial licenses are not the major source of income) I propose: * Set up regression tests, (keep those tests in the open!) * Start a new thread beating the hell out of the API and distilling it to a very simple, solid powerful API. It should be as simple as possible but no simpler - *hat tip* to Einstein. * Then once a good way is found. Make a stabilization _fork_ this is now legacy code. (no one will use it anyway, though it keeps things proper) * Start a rolling release declare that "Evolution of Public Contracts" is not being followed till the API is stable. * implement the new API, strip out python and the extraneous bits leaving the most tight, dependency reduced core possible. (huge refactor here) * declare the API is stable, now it absolutely must follow "Evolution of Public Contracts" * Now you have the real NuPIC. * from now on github.com/numenta/nupic will be the only repository (except that one stabilization fork) and it will _always_ remain stable ready to build off by anyone. Years on, projects that still use the rolling release since the onset of the rolling release will still work as Public Contracts are adhered to. * create repositories for language bindings that follow the same rules. This approach reduces developers headaches, users cursing and keeps things solid _all the times_ There should be no roadmap, feature list, nothing like that, these fall out of date and are useless. What should happen is issues come in and pull requests follow solving the issues with tight succinct code addressing only the issue at hand. The community organically grows and solves problems as they arise. This should be a lazy process, a "pain driven development" such that its painful so someone makes an issue (huge discussion on issue page / squelched or not) and someone fixes it (huge discussion on pull request page / accepted or not). Incremental developments with the entire community scrutinizing every step. I cannot wait for the arguments that'll take place. Kind regards Stewart _______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
