[Freeswitch-dev] version numbers

[Dalei Liu]

Thanks for the inside thoughts.

About 1) and 2), these are things I was looking for and I hope they
may be put into wiki, so all the users and developers will understand
it and stick on it.

Some additional thoughts:
a) What's the definition of the versions with odd number, like 1.1 and
1.3? Reserved for dev or same as even number?

b) About the major releases, my personal opinion is, please try not to
put all new fancy features into one version and release as early as
possible once a feature is ,completed and tested.  If a huge change
affects all the modules and need significant time to develop and test,
it might need a new project version number (major number).

c) Stable releases with same major/minor number do not have to be
strictly limited to bug fixes only.  They may contain small
improvements as far as the new version is a drop-in replacement to the
old one, say, not breaking any existing installation.  In this way, it
will save some minor numbers for really big features.

I believe in release early release often.  To me, if I don't see a new
version released in two years, most likely the project is dead.

About 3), I'm a little confused about "release branches rather than
tarballs" part.  For me, each release has a version number and refers
to a static point of the repository.  A branch is just for developers
to organize patches and can not be released to any one.  I think if a
software has easy installation and excellent compatibility, a user
will have no problem to upgrade it.  Anyway, if there is a bug, he has
no way but to patch it.  I think the best way to reach an audience is
to build package binaries, deb, rpm and exe.

About 4), I completely understand the concern and actually had similar
feeling in some projects.  The way I did/does is, I put everything to
wiki if it doesn't fit a code comment.  Everything is build-able by
scripts and built automatically by cron.  When there is a new comer, I
ask him to review all the documents before he asks any questions, and
add the answers to new questions to the documents.  For anything new
that affects other developers, there should be a document base upon
the agreement, so it becomes an idea of the project instead of an idea
of somebody.