Date: Sun, 27 Jul 2014 12:24:26 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Mark Walters <markwalters1009@gmail.com>
Subject: Re: [PATCH 04/14] new: Don't report version after upgrade
Message-ID: <20140727162426.GF13893@mit.edu>
References: <1406433173-19169-1-git-send-email-amdragon@mit.edu>
	<1406433173-19169-5-git-send-email-amdragon@mit.edu>
	<87y4vfywmp.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y4vfywmp.fsf@qmul.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Mark Walters on Jul 27 at 10:33 am:
> On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> > The version number has always been pretty meaningless to the user and
> > it's about to become even more meaningless with the introduction of
> > "features".  Hopefully, the database will remain on version 3 for some
> > time to come; however, the introduction of new features over time in
> > version 3 will necessitate upgrades within version 3.  It would be
> > confusing if we always tell the user they've been "upgraded to version
> > 3".  If the user wants to know what's new, they should read the news.
> 
> Two thoughts on this: 
> 
> first, we could print the names of the new features here to make it
> easier for the user to find them in NEWS. 

Interesting.  Transparency is good, though I worry that this would
expose the user to internal implementation details (certainly some
features will translate to user-visible features, but others will be
entirely internal to the library).

> Secondly, would it be worth having something like notmuch
> --database-version or similar which prints the features? If I understand
> the series then notmuch clients don't necessarily need to upgrade the
> database unless they want the new features. This means that knowing what
> version they are running might not tell us which features they have
> enabled (which could make debugging difficult)

Good idea, though I'd be inclined to do it in a follow-up series just
so this series doesn't get even longer.  It won't be a problem for
now: this series doesn't touch our current policy of unconditionally
upgrading on notmuch new (a policy I think we should keep, though
that's a separate discussion) so the notmuch version should still tell
us the database version/features.

> Best wishes
> 
> Mark
> 
> > ---
> >  notmuch-new.c        | 3 +--
> >  test/T530-upgrade.sh | 2 +-
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/notmuch-new.c b/notmuch-new.c
> > index d269c7c..b7590a8 100644
> > --- a/notmuch-new.c
> > +++ b/notmuch-new.c
> > @@ -1023,8 +1023,7 @@ notmuch_new_command (notmuch_config_t *config, int argc, char *argv[])
> >  				      add_files_state.verbosity >= VERBOSITY_NORMAL ? upgrade_print_progress : NULL,
> >  				      &add_files_state);
> >  	    if (add_files_state.verbosity >= VERBOSITY_NORMAL)
> > -		printf ("Your notmuch database has now been upgraded to database format version %u.\n",
> > -		    notmuch_database_get_version (notmuch));
> > +		printf ("Your notmuch database has now been upgraded.\n");
> >  	}
> >  
> >  	add_files_state.total_files = 0;
> > diff --git a/test/T530-upgrade.sh b/test/T530-upgrade.sh
> > index 7d5d5aa..c4c4ac8 100755
> > --- a/test/T530-upgrade.sh
> > +++ b/test/T530-upgrade.sh
> > @@ -33,7 +33,7 @@ test_expect_equal "$output" "\
> >  Welcome to a new version of notmuch! Your database will now be upgraded.
> >  This process is safe to interrupt.
> >  Backing up tags to FILENAME
> > -Your notmuch database has now been upgraded to database format version 2.
> > +Your notmuch database has now been upgraded.
> >  No new mail."
> >  
> >  test_begin_subtest "tag backup matches pre-upgrade dump"