[Freeswitch-dev] version numbers
Hi, I've been using freeswitch for a while and really like the stability and sip compatibility. While the code is excellent, I think the version management could be better.
From the git repository, the last tag is 1.0.6 dated a year and half ago, and there was a 1.0.7 announcement but no tag anywhere. As described in the installation guide git repository is strongly recommended but the problem is, it's a changing target. And using SHA1 is really not helpful to the users.
Is it possible to define a formal version numbering system and regular release procedure? For example, if we think the current master is stable enough has the features we need and no major issue, tag it as 1.1-rc1, release it and let the users to test it under all different conditions. And then tag 1.1-rc2, 1.1-rc3, etc until all the the minor issues are either fixed or moved to next minor release v1.2. At that moment, tag and release 1.1 and create a branch b1.1 on master. Later, only the bug fixes go into the branch and it can be tagged as v1.1.1, then 1.1.2, etc. All the new features or enhancements will sit in master and be included in the next minor release v1.2, which will follow the same procedure. In this way, the users will have a fixed target to test and report issues and the developers will have a way to reproduce the same problem. And it will help the users and developers from outside understand the development progress. I believe it will also help integrate freeswitch into mainstream distros, like debian and fedora. My dream is one day, I could just type apt-get install freeswitch from the fresh debian installation. If you think it worths the time, I could contribute some time on it. Best regards, Dalei
You are very right, we get no help in this department so we are slow about fixing it. 1.0.7 is the nick name for the development cycle. We have plans to start a new 1.2 branch soon and we will need stable 1.0 branch managers. We prefer not to produce burned releases because they get stale rather fast based on our development pace. On Wed, Nov 9, 2011 at 2:21 AM, Dalei Liu <daleiliu@gmail.com> wrote:
Hi, I've been using freeswitch for a while and really like the stability and sip compatibility. While the code is excellent, I think the version management could be better.
From the git repository, the last tag is 1.0.6 dated a year and half ago, and there was a 1.0.7 announcement but no tag anywhere. As described in the installation guide git repository is strongly recommended but the problem is, it's a changing target. And using SHA1 is really not helpful to the users.
Is it possible to define a formal version numbering system and regular release procedure? For example, if we think the current master is stable enough has the features we need and no major issue, tag it as 1.1-rc1, release it and let the users to test it under all different conditions. And then tag 1.1-rc2, 1.1-rc3, etc until all the the minor issues are either fixed or moved to next minor release v1.2. At that moment, tag and release 1.1 and create a branch b1.1 on master. Later, only the bug fixes go into the branch and it can be tagged as v1.1.1, then 1.1.2, etc. All the new features or enhancements will sit in master and be included in the next minor release v1.2, which will follow the same procedure.
In this way, the users will have a fixed target to test and report issues and the developers will have a way to reproduce the same problem. And it will help the users and developers from outside understand the development progress. I believe it will also help integrate freeswitch into mainstream distros, like debian and fedora. My dream is one day, I could just type apt-get install freeswitch from the fresh debian installation.
If you think it worths the time, I could contribute some time on it.
Best regards, Dalei
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
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
Thanks for the reply. Here are some thoughts might be useful: 1. Create/update a wiki page about the definition of the version system; 2. Create wiki pages for the goals of each planned version, including stable and dev version, like 1.2, 1.3; 3. Tag the current master to be 1.0.8-rc1 or 1.1-rc1, and set an initial release date for the stable release, e.g Nov 30; 4. Create a branch only if we have to merge master with a major feature not on the goal list of the stable version; The goal for each version can be changed and the release date can be delayed. More RC versions can be released before the formal one. But the most important thing is, the users will have a version to test, to discuss and to fix. About the next release, I feel v1.1 is better than v1.0.8 because it saves a digit for all the following versions (v1.1.3 vs v1.0.8.3, etc). Personally, I'm not a big fan to the odd/even number style. I think all the features in master should be tested and stable enough for integration (otherwise it'd better stay in a branch as branching is very cheap in git). It just needs several beta and RC versions to make it stable. Using a whole minor number for testing is a waste. Again, if you think it worths the time, I would like to start contributing on wiki pages.
The most important thing is to choose a way that works that disturbs me the least. I am open to work it out and you are welcome to participate but my basic principles need to stand. Beliefs I want to stick with: 1) The first number is the project version number, i.e. 1 since its the first complete implementation of a particular strategy. I would never see that version reach 2 unless I did a complete rewrite or changed my attack angle. apache 1.x is forking philosophy and 2.x is threading. 2) The second number is the major release number, each time it goes up its a new milestone. FreeSWITCH 1.0 was dubbed "Phoenix" because it was a new era being born. FreeSWITCH 1.2 will be "Dragon" since I am sticking with mythical beings as it seems. Since FreeSWITCH 1.2 might make drastic changes that other people do not want to endure, I want to permanently branch 1.x as a stable branch where small bugs can still be fixed and possibly pushed up. 3) I want to release branches of GIT rather than just tarballs because we need to be able to deploy quickly. I'm ok with rolling a tarball but people tend to get stuck on them and then we have to fight to get people to test new versions and we get all of our bug reports after its too late rather than before we mark it stable. 4) I do a huge portion of the coding on the project all by myself. So I don't have tons of resources to devote to anything too complicated. I have had volunteers in the past but nobody really seems to fully commit or stick around long enough so I need to make sure I do not let people implement their ideas then disappear and leave us stuck with it. You might want to hang out on IRC irc.freenode.net #freeswitch #freeswitch-dev or visit our weekly conf call sip:888@conference.freeswitch.org every Wednesday 12-Npm CST On Thu, Nov 10, 2011 at 11:25 PM, Dalei Liu <daleiliu@gmail.com> wrote:
Thanks for the reply. Here are some thoughts might be useful:
1. Create/update a wiki page about the definition of the version system; 2. Create wiki pages for the goals of each planned version, including stable and dev version, like 1.2, 1.3; 3. Tag the current master to be 1.0.8-rc1 or 1.1-rc1, and set an initial release date for the stable release, e.g Nov 30; 4. Create a branch only if we have to merge master with a major feature not on the goal list of the stable version;
The goal for each version can be changed and the release date can be delayed. More RC versions can be released before the formal one. But the most important thing is, the users will have a version to test, to discuss and to fix.
About the next release, I feel v1.1 is better than v1.0.8 because it saves a digit for all the following versions (v1.1.3 vs v1.0.8.3, etc).
Personally, I'm not a big fan to the odd/even number style. I think all the features in master should be tested and stable enough for integration (otherwise it'd better stay in a branch as branching is very cheap in git). It just needs several beta and RC versions to make it stable. Using a whole minor number for testing is a waste.
Again, if you think it worths the time, I would like to start contributing on wiki pages.
_________________________________________________________________________ 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
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.
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
Sound great. As everything is planned, do you have a rough estimate of the code need to be done before freeze v1.0? And what's feature list of project dragon? Any target release date for both projects?
Hello, any news with the windows version of G.729 transcoder? Any support needed for that? Thanks, Krisztian -----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Friday, June 18, 2010 8:14 PM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] G.729AB License I am going to try to work on that a bit this weekend. Drop me a line directly next week, and we'll see if we can test this out. Mike On Jun 17, 2010, at 4:53 PM, Bob Coleman wrote:
Hi,
Any news on the windows version? Progress?
_______________________________________________ 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
On Sat, Nov 12, 2011 at 12:45 AM, Dalei Liu <daleiliu@gmail.com> wrote:
Sound great. As everything is planned, do you have a rough estimate of the code need to be done before freeze v1.0? And what's feature list of project dragon? Any target release date for both projects?
We don't really plan too far ahead so far. It's probably a good idea to get into at some point but we haven't thus far. The one major architecture idea we have been considering for a while is a new kind of controller module, something that could plug into the concept of using signalling on a controller box to command the media resources on another but that's been an idea for years now ;) 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
participants (3)
-
Anthony Minessale
-
Dalei Liu
-
Szentesi Krisztián