1. Euphoria Release Cycles
- Posted by jeremy (admin) Jan 03, 2011
- 1460 views
I've been reading around the net and locally and found some disgruntled Euphoria users due to the length of time it took for 4.0 to arrive to its now official status. Indeed it was a long time. I wanted to take a minute to address why this happened and what we have put in place to prevent this from happening in the future.
If you read my response to Programming and Martial Arts you'll find that I (as well as others) believe that Euphoria 3.x was very far behind in times in regards to its contemporaries. You'll also see that due to this, I believe that Euphoria was dying as a language. Thus, something had to be done. If the devs would have made normal release cycles and attempted to play catchup that way, we would have always been way behind the times. Why? Other languages are making the same normal releases, in general. We needed to make one huge push and update to Euphoria to get us on a somewhat even playing field. This would have taken way too long on a normal release cycle. During the development of the 4.0 release the dev team also developed an entire modern web infastructure to support the Euphoria programming language as well as totally new documentation formatting/generation system that modernizes (and keeps code/docs in one place) the generation of the documentation for Euphoria. In addition to the language and standard library we have added a disassembler, unit testing, code coverage analysis and a project documentation system. Further, Euphoria also can now be run on more platforms than ever. All of this took time, a good deal of time.
There was also the fact that we tried to make it easy for users with future releases. We added a new keyword (for example) named public. When doing so we have potentially broke legacy code that may have used the new keyword public as some other symbol in their program. There were many such additions. We did our best to get any breaking changes out in 4.0 so that users did not have to download version 4.0.1 and find out more code is broken, then 4.0.2 and yet more code was broken, 4.0.3 and still.... more broken code. Thus, this greatly increased the scope of 4.0 (in addition to us playing catchup w/modern languages).
All of this is important for attracting new users to Euphoria. This is vital to Euphorias continued existance. We need more core developers and we need more users developing cool Euphoria libraries and applications which will make everyones job easier as more libraries become available for your own use.
Thus, 4.0 had a longer than normal development cycle. Now, what are we doing to prevent this from happening in the future?
Versioning for Euphoria has now taken on a well defined scheme. X.Y.Z. 4.0.0. A .X release is a major release. It is possible that in .X releases something may be incompatibile with previous releases. A .Y release is a minor release but includes core language updates. A .Z release is a bug release and standard library enhancement release.
- .X releases are not on any schedule. They happen when major changes are discussed, found necessary and made.
- .Y releases are not yet on a schedule but as we refine our release system we hope to set some type of time frame on these. .Y releases contain language changes that do not cause incompatibilities with previous releases. They will also include anything that was scheduled for deploy for the next .Z release.
- .Z releases are on a 2 month schedule, 6 times per year or at which point a serious bug is found and fix has been made. .Z releases include bug fixes to core, bundled utilities and the standard library. In addition, .Z releases include enhancements to the standard library. For example, for 4.0.1, join_path, split_path have been added, datetime.e/parse now supports parsing of 2-digit year dates instead of its previous 4-digit years only. Quite a few other standard library enhancements are scheduled for 4.0.1. I'm hoping some more std/net/* protocols will be included for example.
The .Z release cycle is our first step to ensure that there is no longer large spans between releases of Euphoria. What also ensures no large spans between releases of Euphoria is that we are no longer in a massive catchup phase in our development of Euphoria. In some areas we need to catch up, but not such a massive amount of the overall language. You can also view the wiki:EuphoriaRoadmap and wiki:RoadmapBeyond for information regarding .X and .Y release cycles.
I hope that people can understand and take comfort that we should not have long release cycles any longer.
Jeremy
2. Re: Euphoria Release Cycles
- Posted by alanjohnoxley Jan 05, 2011
- 1241 views
IMHO, worth repeating:
Euphoria is open source and is maintained by UNPAID skilled persons, although donations are welcome.
These persons have real jobs and lives too, so the non-contributors should keep that in mind before complaining too much ;)
Thanks guys!
3. Re: Euphoria Release Cycles
- Posted by Vinoba Jan 05, 2011
- 1238 views
Psychologically (for the average user) a message in his email generated automatically by your server with an announcement of a new release (about every 3-5 weeks), is the greatest incentive for him to keep on downloading the latest version and checking. The seasoned user might know that there is hardly any change worth looking at, but the technique is effective and works to create an aura (illusion?) of activity. For example, I would have expected after 3.1, 3.1.4, 3.1.4.3, 3.1.5, 3.1.7, 3.1.8, 3.1.9, 3.1.9.2 etc etc before the start of 4.0 Beta etc I look at about 8 different Euphoria level of programming sites and this is the technique they use. I don't consider it immoral. Certainly it is more moral than announcing a release 6-20 months before it is due (as IBM used to do in the 80s and 90s.
4. Re: Euphoria Release Cycles
- Posted by jeremy (admin) Jan 05, 2011
- 1200 views
Psychologically (for the average user) a message in his email generated automatically by your server with an announcement of a new release (about every 3-5 weeks), is the greatest incentive for him to keep on downloading the latest version and checking. The seasoned user might know that there is hardly any change worth looking at, but the technique is effective and works to create an aura (illusion?) of activity. For example, I would have expected after 3.1, 3.1.4, 3.1.4.3, 3.1.5, 3.1.7, 3.1.8, 3.1.9, 3.1.9.2 etc etc before the start of 4.0 Beta etc I look at about 8 different Euphoria level of programming sites and this is the technique they use. I don't consider it immoral. Certainly it is more moral than announcing a release 6-20 months before it is due (as IBM used to do in the 80s and 90s.
I'm not sure what you are trying to say here, but the 2 month cycle for releases is not to create an illusion of activity. It's to create consistency. There have already been bug fixes to 4.0 which will benefit some people and there have been a few methods added to the standard library that were found to be missing on 4.0 releases. By the time 4.0.1 is ready to be released, there are some 30 methods that will have been added, quite a few document fixes a few new features and who knows what other bugs will be found/fixed before that time arrives.
The 4.0 release took a little more than 1/2 a day to release. Building all the sources, compiling for the platforms, updating download sites, uploading packages, switching operating systems, compiling on new operating systems, etc... You can be rest assured I am not going through all that work to release a new version of Euphoria that includes 1 bug fix and 1 new method. If release time comes and that's all that is in the queue for deployment, here on the forum a prompt message will appear stating no release will be made (unless of course it's a monsterous bug affecting a wide range of applications/people, if that's the case a bug release will be made ASAP, prior to the 2 month deploy point).
In reality what it does is provide incentive for developers to keep on track. We know a release is coming up and we know ABC and XYZ should be completed for that release. .z releases will always contain some things of value for the users. Now, maybe 4.0.2 is released and it contains the FTP, STMP, POP3 and IMAP libraries. That's a serious amount of code, but maybe you don't use any networking at all. Sure, that release will be of nothing to you, but Euphoria serves more than one person. I for one would be estatic to get an FTP library because I rely on it quite a bit in a few applications for my work. A release such as the one just stated, I'd be jumping for joy for while someone else may say "Huh? Why bother releasing?"
Jeremy
5. Re: Euphoria Release Cycles
- Posted by jeremy (admin) Jan 05, 2011
- 1253 views
I just figured I would point out that anyone can view the changes and work being done to Euphoria by simply looking at the SCM change log. It's public and visible to all. There really is quite a bit of activity. Maybe not as much as projects with a 20 or 30 core devs, but we've not done bad at all. We've been ranked pretty highly w/SF.net for many weeks in a row on many occassions, we've held the front page of cia.vc for full days at a time quite a few times (pitted against projects such as KDE, Gnome, FreeBSD, Python, GenToo, ...). Anyway, take a peek. Today is not an exceptional day but not a slow day either. 13 commits so far, day is half over here. 61 over the past 7 days. A commit is each time a logical step has been made. A commit in some cases is a single line bug fix. In other cases a 200 line std library addition. From 4.0a1 to 4.0 final there were around 3,500 such commits. According to CIA.vc project stats, over the last 2.64 years we averaged a commit every 4.78 hours.
The SCM commit log: hg:euphoria
Jeremy
6. Re: Euphoria Release Cycles
- Posted by Vinoba Jan 06, 2011
- 1185 views
I was NOT implying that there is no activity, and certainly did not mean to offend. I was trying to bring to your attention how THE MASSES view any of the software products, particularly the low priced or free ones. 1. They want an APPEARANCE of activity. 2. When emails come with announcement of new release, to them that is THE evidence of activity. 3. If the email confirms with a URL to a download right in front of the eyes IN the email, that is better confirmation. 4. Also this ordinary software developer wants to FORWARD this email to his 4 buddies to ask them to see what THEY think of a particular change or two. 5. I am a fairly knowledgeable person, and have used Sourceforge, etc for at least 10 years, but I rarely bother to look at daily and weekly changes and SVN etc. Frankly I do not have the time for it.
So it boils down to what the masses THINK of the level of activity. In computer clubs, and also in groups of like minded friends, in the breaks in a software demo, etc, we always discuss whether there is another release of XYZ, not about the content or relevance. The comparisons are often about whether XYZ also had a new release, NOT about comparing features.
