It took me a lot longer than what I would have liked, but I managed to start working on the next version. Branching the program needed quite a bit of work, as there were many changes in the tools that do the building and packaging. Well, here's how it's supposed to work:
The new, "development" branch is called "unstable" and it gets its own place at the SourceForge download page, which mirrors the directory structure of the "stable", 1.0 release. The files' names contain "unstable", though. Version names will be 1.1.01, 1.1.02, ... until a new stable release will be created (probably 1.2)
In Subversion this new development takes place in trunk, while there is a new "1.0" branch created for the stable release. (Even though it's technically incorrect from Subversion's point of view, I will call the "1.1.x" release the "unstable branch", to emphasize that most people should keep using 1.0, which is for now the main, stable release.)
There is a separate on-line help system for the unstable branch. For now it's just a copy of 1.0, but that will change.
The Linux and Windows unstable binaries that I provide at SourceForge and OBS can be installed alongside the "stable" ones. Getting this to work wasn't very easy, but it seemed important. The "stable" and "unstable" versions are not aware of one another and normally they should use different sessions (they can be made to share sessions, but this is best avoided - making a copy would be preferred). Notification for new versions being available is also separate for the stable and unstable branches.
In 1.1.01 there is nothing new over 1.0.08 from a functional point of view. The changes mainly deal with the idea that the program knows that it's "unstable". Well, for the Windows build I switched to the latest Qt/MinGW, and this might have some impact, although I didn't notice anything. (I also plan to look at Visual Studio Express to see if it can make the program smaller.)
So basically 1.1.01 is for those curious to see if there is any negative impact from these changes, in which case I hope I will get notified. (I also noticed that the Linux binaries don't work as well as they did in the past, but this is an issue for 1.0 as well as 1.1)
For the casual users, it's better to stick to 1.0 until a new stable version gets released or there seems to be some really important feature in 1.1. While 1.1.x releases will get tested, 1.0 was tested more thoroughly. Also, I won't try very hard to keep setting or data compatibility in the unstable release, but I don't expect this to be a big issue.
Tuesday, May 31, 2011
MP3 Diags 1.0.08 available
Nothing very exiting for this release - its main purpose is to add a half-fix for a crash before splitting the code to start working on version 1.1. There were some crashes reported when trying to save changes, which didn't make much sense, but investigating them led me to discover a related bug that is fixed now (although the original bug probably remains unfixed). Well, even if the change just managed to make that bug invisible, it seems to have solved the problem for the user, so I guess it's better to publish the fix now rather than wait for a full understanding of what was going on.
If you didn't experience crashes at startup or when saving, there's no point in upgrading.
There are also some script changes, in the tools that prepare the packages, not in the program's code. These are also related to the 1.1 split. I hope I didn't break anything; at any rate, I tested them and they seemed OK.
If you didn't experience crashes at startup or when saving, there's no point in upgrading.
There are also some script changes, in the tools that prepare the packages, not in the program's code. These are also related to the 1.1 split. I hope I didn't break anything; at any rate, I tested them and they seemed OK.
Subscribe to:
Posts (Atom)