incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [REQUEST] Binaries for 1.3.0-rc.3
Date Tue, 16 Apr 2013 14:16:52 GMT
Okay, thanks for the explanation. That's fine! :)


On 16 April 2013 15:08, Jan Lehnardt <jan@apache.org> wrote:

> It is a user experience nightmare.
>
> Steps to intall a zip app:
>
> 1. Download
> 2. Double Click (in Safari downloads, in the downloads springload in the
> Dock or in the Finder)
> 3. Double Click the resulting .app.
>
> Steps to install a dmg app:
>
> 1. Download
> 2. (if automount is enabled), navigate to a Finder with a sidebar. (if
> not, double click)
> 3. Open the mounted disk image.
> 4. copy/move the app to /Applications or whereever // insert rant about
> sidebar-less Finder window configuration.
> 5. Eject the dmg.
>
> If at 4, people just open the app, they can’t unmount the image (5) and
> the app is trapped there forever. On top of that, why add a confusing layer
> of complexity for no good reason?
>
> The .dmg is a horrible cargo-cult from the early days of the Mac’s history
> and has been discouraged for a very long time (let it be 2004). I’m happy
> to dig up a few old articles that discuss this in more detail, but I hope
> this suffices.
>
> tl;dr: no benefits, horrible user experience, lets not cargo-cult.
>
>
> Best
> Jan
> --
>
>
>
>
>
>
>
> On Apr 16, 2013, at 15:32 , Noah Slater <nslater@apache.org> wrote:
>
> > Any reason, Bob? I'm trying to understand what the facts are. Without
> > knowing what the pros and cons are, I am unable to hold any opinion on
> the
> > subject. All I know is that every app I ever download for OS X comes
> with a
> > .dmg. CouchDB is the only app I have downloaded on my current laptop that
> > expands from a .zip file. That's enough to make me question our choice.
> But
> > I really don't have any other information on the subject.
> >
> >
> > On 16 April 2013 14:28, Robert Newson <rnewson@apache.org> wrote:
> >
> >> +1 for keeping .zip.
> >>
> >> B.
> >>
> >> On 16 April 2013 14:26, Noah Slater <nslater@apache.org> wrote:
> >>> Any reason?
> >>>
> >>>
> >>> On 16 April 2013 14:21, Jan Lehnardt <jan@apache.org> wrote:
> >>>
> >>>>
> >>>> On Apr 16, 2013, at 14:36 , Noah Slater <nslater@apache.org> wrote:
> >>>>
> >>>>> Hmm. You raise an interesting point. The .app file should certainly
> >> not
> >>>>> have version numbers in it. But it seems conceivable that the .zip
> >> file
> >>>>> might. Do we ever plan to use a .dmg file instead of .zip?
> >>>>
> >>>> No.
> >>>>
> >>>>>
> >>>>>
> >>>>> On 15 April 2013 19:34, Jan Lehnardt <jan@apache.org> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Apr 9, 2013, at 18:38 , Noah Slater <nslater@apache.org>
wrote:
> >>>>>>
> >>>>>>> Jan,
> >>>>>>>
> >>>>>>> In this directory:
> >>>>>>>
> >>>>>>> http://www.apache.org/dist/couchdb/binary/mac/1.3.0/
> >>>>>>>
> >>>>>>> The binaries lack a "1.3.0" in the filename. I noticed this
when
> >>>> updating
> >>>>>>> the links on our website, because they broke, with the new
filename
> >>>>>>> pattern. I think it would be good to standardise on a filename
with
> >> the
> >>>>>>> version number in it.
> >>>>>>>
> >>>>>>> However, because these are convenience binaries, I am going
ahead
> >> with
> >>>>>> the
> >>>>>>> release announcement. If you roll some new binaries with
an updated
> >>>>>>> filename, just wait the usual 24 hours for the mirrors to
sync and
> >> then
> >>>>>>> update the website links.
> >>>>>>
> >>>>>> I don’t think the file names should have the release version
in
> them,
> >>>> but
> >>>>>> I can be persuaded to do it for the Apache-CouchDB-x.y.z.zip,
but
> the
> >>>>>> resulting .app should always be called “Apache CouchDB.app”
to be in
> >>>> line
> >>>>>> with Mac system standards.
> >>>>>>
> >>>>>> Best
> >>>>>> Jan
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 1 April 2013 14:49, Jan Lehnardt <jan@apache.org>
wrote:
> >>>>>>>
> >>>>>>>> I managed to work around some of the issues in an ad-hoc
way. This
> >>>> whole
> >>>>>>>> thing
> >>>>>>>> needs cleaning up.
> >>>>>>>>
> >>>>>>>> The preliminary binaries are up on
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >> https://dist.apache.org/repos/dist/dev/couchdb/binary/mac/1.3.0/rc.3/
> >>>>>>>>
> >>>>>>>> To test:
> >>>>>>>> - download
> >>>>>>>> - verify signatures*
> >>>>>>>> - unzip
> >>>>>>>> - double click (make sure no other couch is running
on 5984
> >>>>>>>> - wait for Futon to auto-open in your browser
> >>>>>>>> - navigate to “Verify Installation”
> >>>>>>>> - click on “Verify Installation”
> >>>>>>>> - if all is green, all is well.
> >>>>>>>>
> >>>>>>>> Thanks!
> >>>>>>>>
> >>>>>>>> Jan
> >>>>>>>> --
> >>>>>>>> * verify signatures:
> >>>>>>>>
> >>>>>>>> md5sum --check Apache-CouchDB.zip.md5
> >>>>>>>> sha1sum --check Apache-CouchDB.zip.sha
> >>>>>>>> gpg --verify Apache-CouchDB.zip.asc
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Apr 1, 2013, at 13:25 , Jan Lehnardt <jan@apache.org>
wrote:
> >>>>>>>>
> >>>>>>>>> I’m currently blocked by
> >>>>>>>> https://github.com/iriscouch/build-couchdb/issues/77
> >>>>>>>>>
> >>>>>>>>> cc Jason
> >>>>>>>>>
> >>>>>>>>> Jan
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> On Mar 31, 2013, at 16:19 , Noah Slater <nslater@apache.org>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>>> Dear community,
> >>>>>>>>>>
> >>>>>>>>>> This is a request to prepare binaries for the
1.3.0-rc.3
> release.
> >>>>>>>>>>
> >>>>>>>>>> Please follow the release procedure:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Binary_Packages
> >>>>>>>>>>
> >>>>>>>>>> Everyone is welcome to prepare binaries for
this release.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> NS
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> NS
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> NS
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> NS
> >>
> >
> >
> >
> > --
> > NS
>
>


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message