We probably will not be talking about the odd ones very much, I think we just do even for vanity sake.<div><br></div><div>Yes releasing branches is our own radical idea that we want to implement.</div><div><br></div><div>This basically means a stable branch.</div>
<div><br></div><div>1.0 branch will slow down to a crawl and people who are paranoid latch onto that and the community maintains it.</div><div>1.2 branch (HEAD) will continue business as usual.</div><div><br></div><div>some day we then release 1.4 and 1.2 becomes a branch and 1.0 slows down even more.</div>
<div><br></div><div>Then when they are older it&#39;s easier to make tarballs out of them.</div><div><br></div><div><br><br><div class="gmail_quote">On Fri, Nov 11, 2011 at 12:38 PM, Dalei Liu <span dir="ltr">&lt;<a href="mailto:daleiliu@gmail.com">daleiliu@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks for the inside thoughts.<br>
<br>
About 1) and 2), these are things I was looking for and I hope they<br>
may be put into wiki, so all the users and developers will understand<br>
it and stick on it.<br>
<br>
Some additional thoughts:<br>
a) What&#39;s the definition of the versions with odd number, like 1.1 and<br>
1.3? Reserved for dev or same as even number?<br>
<br>
b) About the major releases, my personal opinion is, please try not to<br>
put all new fancy features into one version and release as early as<br>
possible once a feature is ,completed and tested.  If a huge change<br>
affects all the modules and need significant time to develop and test,<br>
it might need a new project version number (major number).<br>
<br>
c) Stable releases with same major/minor number do not have to be<br>
strictly limited to bug fixes only.  They may contain small<br>
improvements as far as the new version is a drop-in replacement to the<br>
old one, say, not breaking any existing installation.  In this way, it<br>
will save some minor numbers for really big features.<br>
<br>
I believe in release early release often.  To me, if I don&#39;t see a new<br>
version released in two years, most likely the project is dead.<br>
<br>
About 3), I&#39;m a little confused about &quot;release branches rather than<br>
tarballs&quot; part.  For me, each release has a version number and refers<br>
to a static point of the repository.  A branch is just for developers<br>
to organize patches and can not be released to any one.  I think if a<br>
software has easy installation and excellent compatibility, a user<br>
will have no problem to upgrade it.  Anyway, if there is a bug, he has<br>
no way but to patch it.  I think the best way to reach an audience is<br>
to build package binaries, deb, rpm and exe.<br>
<br>
About 4), I completely understand the concern and actually had similar<br>
feeling in some projects.  The way I did/does is, I put everything to<br>
wiki if it doesn&#39;t fit a code comment.  Everything is build-able by<br>
scripts and built automatically by cron.  When there is a new comer, I<br>
ask him to review all the documents before he asks any questions, and<br>
add the answers to new questions to the documents.  For anything new<br>
that affects other developers, there should be a document base upon<br>
the agreement, so it becomes an idea of the project instead of an idea<br>
of somebody.<br>
<div><div></div><div class="h5"><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
</div>