Hi,
here's my quick input on parts of the vid, sorry if I skipped something
(it's lengthy and makes me wanna go for a lunch..)
Versioning:
+1 on semantic ver. (x.y.z)
major X releases are important for customers (as it can break their
pipelines)
feature releases are interesting for users (new shiny stuff) and
developers (so their development works dont collide).
we should use git tags for that, and even "human readable tags" - ei
"clang_added", "python26_dropped", "armv7"
Releases:
(probably) -1 on (numeric) versioning at all:
my concern is, version numbers will grow quickly so soon it'll be hard
to keep reasonable sence (still maybe some value for business cust.)
what i'd worry is slowing of the release process and making it harder
to push changes upsream - merge windows, release dates, feature freezes.
While it works for estabilished and huge OSS projects, NuPIC is still young
and with many work to do. And while it'd probably suit you as a full time
dev where you work towards some issue in a longer plan, open-source
contributions happen spontaneously (fix something, implements this and
that). That's why I like so much git and the "only one master" idea, so you
should "release early and release often". (Nupic is great on this but I
must include traditional
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar )
-> so how about a rolling-release progress with a tagged customer version
based on your evaluation, (harder than normal) testing every now and then?
Branches & forking:
-1 on forking. If I understood that.. It seems completely against the git
idea. Git makes it easy to "fork (naming conflict)" to a new branch. It's
very smart for space efficiency (ei I have like 10 branches for nupic, I'd
go crazy having 10 "forks"=repositories).
For new feature development, it should count that 1 feature = one branch.
Bug fixes along the way can flow both directions, from master to my feature
br., and from feature branch to a "bugfix-this" branch -> to master.
Someone mentioned testing - so you could either fork(=pull) my feature
branch, and do your tests and submit results back to the feature.
What I liked from the "forking" idea - one master/HEAD everyone develop
against (we have it).
Again, for versions, use tags: git checkout tags/v1.2.3
As a side note,
to speed up "upstreaming" (if it's feasible for how fast can you rerun
internal tests?) we could adopt the signoff concept from eg linux (kernel).
ALL=passing travis. (Obvious) bugfix-only (_._.z) =one signoff from a
committer. New feature = 2 signoffs from reviewers. (or just 1 signoff if
it's completely new functionality(?) - cant break anything, eg. adding
armv7,...). Major API break (*)...wait for the right time :) Of course
there's a problem what's a bugfix/feature sometimes. But maybe we could try
that.
*) we could have the release dates here, ie 2x a year API breaks :) Or even
better, do major release when needed and then you could use the fork-idea
and keep 2.x, 3.x in separate repos. And ie say each major rel will have
support for +1yr after it's superceeded by a new major. But then,
development should be done against master only, so new features shouldnt be
blocked on problems with older major(s) - so maybe the feature wouldnt be
avail for that old version, git's very capable at merging and rebasing.
....too long already :)
Cheers,
On Thu, Nov 14, 2013 at 4:57 AM, Matthew Taylor <[email protected]> wrote:
> A few of us at Numenta had an ad-hoc lunchtime discussion about versioning
> and releasing for NuPIC. I recorded it, and I thought I would share with
> you and solicit feedback.
>
> http://www.youtube.com/watch?v=z6dKHO9mcUQ
>
> The main open question at this point is whether to release on branches on
> the main repo, or forks. There's a lot of discussion of this in the video
> above. If you have an opinion on the matter, we would like to hear it.
>
> ---------
> Matt Taylor
> OS Community Flag-Bearer
> Numenta
>
> _______________________________________________
> nupic mailing list
> [email protected]
> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
>
>
--
Marek Otahal :o)
_______________________________________________
nupic mailing list
[email protected]
http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
