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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-dev mailing list FreeSWITCH-dev@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900