[Freeswitch-dev] version numbers

[Anthony Minessale]

We probably will not be talking about the odd ones very much, I think we
just do even for vanity sake.

Yes releasing branches is our own radical idea that we want to implement.

This basically means a stable branch.

1.0 branch will slow down to a crawl and people who are paranoid latch onto
that and the community maintains it.
1.2 branch (HEAD) will continue business as usual.

some day we then release 1.4 and 1.2 becomes a branch and 1.0 slows down
even more.

Then when they are older it's easier to make tarballs out of them.



On Fri, Nov 11, 2011 at 12:38 PM, Dalei Liu <daleiliu at gmail.com> wrote:

> 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.
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20111111/59a9c0e8/attachment.html