-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like this idea. It is straightforward and commonly used, not just at ASF.
I don't see any reason we can't go ahead and move existing files under their own version folders. We would may need to update some documentation pages for installs and upgrades if they link directly to downloads. If we go this route, I'd like to go ahead and move the 2.4.1 release soon so that things are already in place using the version folders when we announce 2.4.1. Josh On Thursday, March 26, 2015 12:34:38 PM Andy Kurth wrote: > There is some flexibility in how a project's dist directory is organized. > It seems pretty common for projects to create a directory for each > version. We could begin doing this and put the script files in each > version directory: > dist/vcl/2.4.2/vcl-install.sh > dist/vcl/2.4.2/vcl-install.sh.sha1 > dist/vcl/2.4.2/vcl-install.sh.asc > > We could then create a symlink named something like "current" which points > to the most recent release: > dist/vcl/current -> dist/vcl/2.4.2/ > > Correct me if I'm wrong because I'm no signing expert, but wouldn't things > work correctly if someone were to download: > dist/vcl/current/vcl-install.sh > dist/vcl/current/vcl-install.sh.sha1 > dist/vcl/current/vcl-install.sh.asc > > There is a precedent for using symlinks. See: > https://archive.apache.org/dist/flume/ > https://archive.apache.org/dist/pig/ (using "stable" and "latest") > https://archive.apache.org/dist/zookeeper/ (using "current" and "stable") > > If something like this is agreed upon, would there be anything preventing > us from moving existing releases into directories? > > -Andy > > On Thu, Mar 26, 2015 at 10:34 AM, Josh Thompson <[email protected]> > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > When creating the vcl-install.sh and vcl-upgrade.sh scripts, I planned to > > be > > able to distribute them separately from the release artifacts (in addition > > to > > being within the artifacts) so that someone only needs to download the > > script, > > and the script will handle downloading and validating the artifact. It > > makes > > sense to distribute them from the same dist location as the release > > artifacts > > since that is the official release location. The scripts contain the > > version > > number to install. Because they have a version number, they need to be > > updated in the dist location for each release. However, for the same > > reason > > that we couldn't update the 2.4 release after the bug was found in it > > before > > we announced it, we can't just update the files with each release without > > triggering a possible security issue. > > > > As a solution, I thought maybe we could have scripts in the dist location > > that > > have a version number as part of the file name and use symlinks to point > > to > > the latest version, updating the symlinks at each release. However, this > > doesn't work for the signature files, since the signature files have the > > original filename in them (that includes the version number). So, when an > > attempt to verify the signature is done, the file listed in the signature > > is > > not found. As an example: > > > > download vcl-install.sh (which is a symlink to vcl-install-2.4.1.sh) > > download vcl-install.sh.sha1 (which is a symlink to > > vcl-install-2.4.1.sh.sha1) > > verify .sha1 file: sha1sum -c vcl-install.sh.sha1 > > sha1sum: vcl-upgrade-2.4.1.sh: No such file or directory > > > > Interestingly, verifying the .asc GnuPG signature still works. > > > > Before attempting yet another solution that may not work, I thought I'd > > bring > > it up on the list to seek input. What I'm thinking to do now is to add a > > 'scripts' directory under the dist folder. Then, add version number > > folders > > under there, with the install and upgrade scripts in each version number > > folder, like: > > > > dist/vcl/scripts/2.4.1/vcl-install.sh > > dist/vcl/scripts/2.4.1/vcl-install.sh.sha1 > > dist/vcl/scripts/2.4.1/vcl-install.sh.asc > > dist/vcl/scripts/2.4.1/vcl-upgrade.sh > > dist/vcl/scripts/2.4.1/vcl-upgrade.sh.sha1 > > dist/vcl/scripts/2.4.1/vcl-upgrade.sh.asc > > > > When the next version comes out, we would just add a new release number > > under > > the scripts folder. > > > > Does this sound like a good idea? Other suggestions? > > > > Thanks, > > Josh > > - -- > > - ------------------------------- > > Josh Thompson > > VCL Developer > > North Carolina State University > > > > my GPG/PGP key can be found at pgp.mit.edu > > > > All electronic mail messages in connection with State business which > > are sent to or received by this account are subject to the NC Public > > Records Law and may be disclosed to third parties. > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iEYEARECAAYFAlUUGOwACgkQV/LQcNdtPQPvTwCbBfQkNbODUBJ+q+ix6oqqvRs2 > > S4gAn33QxEo37/+3SS1+YGqM+hca6w7K > > =2aUo > > -----END PGP SIGNATURE----- - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUURpEACgkQV/LQcNdtPQORvgCfagVxMOjczEtIEVHqtJwrvyIH vowAniZxTw0eYubSx83/IF6tEmLejN8z =7Bif -----END PGP SIGNATURE-----
