The basic problem with our Sf.net downloads page is nobody has had time to restructure/update it for the new Sf.net downloads system. Current structure (release names, categories etc) was thought out for the old system. When Sf.net updated the system they did some automatic conversion and that didnt' work particularly well in our case.

From my (and from users) point of view that page should offer easy and fast way for the user to find our latest and greatest stable release and download it. Users don't care about beta releases and "experimental" releases could be hidden behind some button (which unfortunately is not possible). So it is about last stable release which we really care about. It probably should be the first thing users see in the page.

I think it is best to start by background information, why things are as they are. It is not random, there are (or were) very good reasons for almost everything. And most things are result of (sometimes) long discussions.

We have the first number in release names ("1. Stable versions") because that was the way order release categories in old system. Apparently it doesn't work in new system and the number can be removed.

"Documentation" category is ancient left-over. We earlier released manual in own category. I think it was for easier manual updates after releases or something such. But we don't need that anymore. So that category can be removed.

"Experimental builds" is the most confusing part for people. And I've seen quite a many different "explanations" which don't have anything to do with reality. The "experimental builds" started as a way to test certain patches in 2.1.x development. We wanted to allow more people to test certain patches and so couple of developers (Perry and Laoran) started adding such "patch-testing" releases to our download page. Originally they were always for testing patches which were NOT applied to version control. And we certainly didn't do these builds regularly - but when needed more testing for patches. Then same people started doing "double releases" - one version for current version control code and another for version control code + patch applied. So it was easier to compare how patch affects. And hence the version control builds were given "(CVS)" suffix to differentiate from releases with patches. Once we converted to using Subversion the suffix was changed to "(svn)". So that suffix has been obsolete since 2.2.0 stable release. We just continued using it to make it more obvious is it SVN snapshot build. So the "svn" is not really about technology or service but that it is current code snapshot build.

Then same people also started doing more regular SVN snapshot builds. So we had to invent version numbering and naming scheme for those releases. I think we called them first as "snapshot" or something like that. But users didn't have idea what those were so after couple of changes we've ended up with "experimental" name for the releases. It is still weird name (though descriptive one). Maybe we should start using "Alpha" as lots of other projects do? Anyway, after others got bored to releasing these snapshot builds I've been continuing doing it as these snapshot builds offer lots of valuable feedback to developers. Most users don't have tools to build WinMerge.

And perhaps we really need to attach the "alphaness" to our release names too ("2.13.14 Alpha"). As most download sites don't know about our experimental status and some people download them as "latest version" of WinMerge.

Developer tools category is also interesting. We added it as a way to distribute easy-to-deploy package for building manual. If one needs to setup all the tools manually to build manual it really takes some time and it is easy to get wrong. Tim created tools structure that can be just unzipped and it works! But this is only for people interesting to work with manual, not for users.

7-zip plugin is a LOOONG story. And had perhaps the longest discussion we've had between WinMerge developers. But in summary we wanted to distribute the archive support plugins as separate from actual WinMerge releases. So that they can be independently updated when needed. We can't release new WinMerge version every time 7-zip is updated. So this is actually important for the users.

I hope this clears some confusion about a bit weird things we have now.

sf-mensch wrote:* beta => "Beta versions" (suggesting that new releases here contain Beta in the name)* alpha => "Alpha versions (experimental builds from current code snapshots)" (dropping "(svn)" from the subfolders and suggesting that new releases here contain Alpha in the name)

There are actually two things to consider here:

release name (label)

release file naming scheme

The important point is that release name is only visible in sf.net downloads page (and in WinMerge.org web page I assume). But lots and lots of people download WinMerge from 3rd party download sites which only see the filenames. So adding Alpha/Beta to release name helps but it is one part of the solution. Perhaps we need to start adding Alpha/Beta status to also released file names? File naming may feel totally separate item, but it may also be superfluous to read Alpha/Beta from package name, release name, version number... So there is some connection to consider.

sf-mensch wrote:* 7-zip-plugin => "7-Zip plugin (independently of WinMerge version)" <-- this label has to be worked on

Would be good if this was somehow connected (near?) to stable releases for making it easier to find. But I understand it may not be practical.

sf-mensch wrote:* dev-tools => "Tools for WinMerge developers"

Sounds good.

sf-mensch wrote:If the folder structure is OK I suggest to change it, we can work on the correct labels afterwards.

Looks good to me. Do the direct links to files change if we change structure? Because again lots of sites link to specific files (=installers) to our releases and breaking link to stable release links makes it "unavailable" for users of those sites.

kimmov wrote:Do the direct links to files change if we change structure? Because again lots of sites link to specific files (=installers) to our releases and breaking link to stable release links makes it "unavailable" for users of those sites.

gerundt wrote:We should maybe later also add a news entry to SF about the restructuring.

Unfortunately that doesn't help practically any user. Sf.net is developer site and I doubt many users read news feed from there. And I doubt admins of other download sites read them either. Some people who are actively submitting our releases to other services may notice and even be able to update links. Most of the time those links can't be altered after submissions.

But of course it would be probably good to tell people about this change. At least it will be a signal that the change was something we did to improve the service.

But I really hope most sites link directly to files so those links won't be affected.

The "/wrong folder/2.13.13 (svn)/WinMerge-2.13.13-exe.7z" file could not be found or is not available. Please select another file.

. This is acceptable.

We could rename old versions, too but not via that nice SF interface (would need weeks...). Maybe via SFTP/SCP/Shell services (I would need Shell rights for that). For all this renaming we have to keep in mind one thing - the file counters for these files are likely to be reset.I've asked on SF support IRC and that's what I was answered

@ctsai-sf wrote:sf-mensch: okay, so, the behaviour's changed since the last time I checked. In my testing, renaming a file via the regular File Manager did NOT reset the download counter. However, the counts in the Beta File Manager (and Beta Statistics) was reset for those files.Renaming a file and renaming a directory resulted in the same behaviour (counters not reset in regular, but reset in Beta).

Christian wrote me that he is willing to add me to WM project. Therefore we can begin if we have a decision and he knows what rights I need.

sf-mensch

Last edited by sf-mensch on Mon Sep 06, 2010 7:31 am, edited 2 times in total.