Consistency of release packages

Just noticed when helping someone having problems with installation, that our .zip download package for 0.9.1 is different in structure than the .tar.gz and tar.bz2 versions. The .zip starts directly at the root of the site, extracting /assets/, /install/, /manager/, etc. while the others include a root directory called /MODx-0.9.1/, so it extracts as /MODx-0.9.1/assets/, /MODx-0.9.1/install/, /MODx-0.9.1/manager/, etc. I think this inconsistency might be a little confusing when trying to install MODx the first time, especially users with less experience with PHP/MySQL CMS systems. However, I’m not sure what the proper structure should be, as when I extract into a local development environment, I would prefer to be working with a subdirectory of the Apache document root (though probably not one with mixed-case letters and the version included in it), while when extracting a package on a remote server, I would rather extract it directly into the location I choose to put it, instead of in a subdirectory of that location. Of course, I generally do not extract my local test environment as /modx-0.9.1/, so even with local extractions, I’d create a new subdirectory first, and then want it at that location (just like on a remote server).

Anyone else have any other thoughts on this subject?

I personally think that not including this parent directory is preferrable, though we might want to update the installation documentation to reflect this. Then again, I’m certainly willing to change my mind if anyone has a compelling argument to the contrary...

Not including a "wrapper" directory can lead to someone inadvertantly extracting to a location then not transferring everything. It’s very easy to move things out once they’re extracted. I say update the install instructions to make sure people know to transfer the contents of the folder, or to move the files once transferred to their intented destination. Lowest common denominator in this case.

I don’t guess I completely understand the issue you are describing with not transferring everything without the wrapper, but mind if we vote on this one? I’m just not in agreement (yet); it may be that you have the majority opinion, but this is a long-standing personal preference of mine, to never use wrapper folders inside of archives to be extracted, and I don’t want to just compromise without a little-bit of a stand. It’s easier to extract everything into the proper location rather than move each individual item down a level if you don’t want it in a subfolder, especially in situations where users have minimal control over the remote server environment or are using tools to extract the archives remotely. Consider our SVN checkouts as an analagous process, if I checkout tattoo/trunk/, I don’t expect /trunk/... to be created in the location I specify to checkout this archive, I expect the contents of tattoo/trunk/.

Except when you do an export of trunk, you get the containing folder, "trunk", which is a final deployment system not for code development. At least in my subversion client.

Well, to be fair, in subversion, the command line allows an optional parameter to define what the package is exported or checked out as, e.g. trunk/ becomes whatever I specify for the location in the SVN client. But if you feel strongly that this will avoid installation issues, and since I generally repackage a site after working on it locally before putting it on a remote server anyway, it’s not that big of an issue to me, as long as we make it clear in the installation instructions (if it’s not already).

Personally, I like it when somefile.tar.gz unpacks into a single folder somefile. This allows me to inspect whats in there without it interfering (overwriting) other files that may have the same name. I’ve downloaded tons of stuff - say to my desktop, and unpacked it only to find out there wasn’t some wrapper folder to hold it all and instantly my desktop is awash in an enless see of files with cryptic names... making it hard to tell which ones I want to delete, and which were there to begin with.

Of course I "could" do this manually be creating a blank directory, and then unpacking there. But I prefer when the developer has done that for me. If I want the contained files elsewhere, a simple Ctrl-A drag and drop or mv * does the trick.

Additionally, I DO like the version being included. From my perspective (which I know is different than the average user), I like being able to install different versions to conduct testing. I had a boss who always told me: "don’t sink your old ship till the new one floats." I can always rename it something more to my liking if I desire.

Hemm.. I would like to know more about this SVN thing though. Why don’t we use Trac for the SVN frontend? Or you guys already have one?

As far as for my suggestion, I prefer to have a subfolder in it, with the same thought like JaredC said in his post. I don’t think it will be hard, if we explain it clearly in the documentation.
What do you guys think?

Trac is nice, agreed...

To my knowledge, SVN is not open outside the dev team, there is no repository to connect to like I was used to have with Textpattern.

No big deal given the rapid release cycle though