[PATCH v3 03/13] new: Don't report version after upgrade
On Sun, 24 Aug 2014, Austin Clements wrote: > Quoth Jani Nikula on Aug 23 at 6:39 pm: >> On Fri, 01 Aug 2014, Austin Clements 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. >> >> I think this is good for now. >> >> What do you think about adding notmuch_database_get_features(), and >> printing that? > > Mark had a similar comment, so here's my reply: > id:20140727162426.GF13893 at mit.edu > > I'm happy with adding more transparency around this, though I'd prefer > to do it as follow-up to avoid expanding this series and because I'm > pretty sure adding something like notmuch_database_get_features > wouldn't require any non-trivial changes to the stuff in this series. Agreed. BR, Jani.
Re: [PATCH v3 03/13] new: Don't report version after upgrade
On Sun, 24 Aug 2014, Austin Clements amdra...@mit.edu wrote: Quoth Jani Nikula on Aug 23 at 6:39 pm: On Fri, 01 Aug 2014, Austin Clements amdra...@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. I think this is good for now. What do you think about adding notmuch_database_get_features(), and printing that? Mark had a similar comment, so here's my reply: id:20140727162426.gf13...@mit.edu I'm happy with adding more transparency around this, though I'd prefer to do it as follow-up to avoid expanding this series and because I'm pretty sure adding something like notmuch_database_get_features wouldn't require any non-trivial changes to the stuff in this series. Agreed. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3 03/13] new: Don't report version after upgrade
Quoth Jani Nikula on Aug 23 at 6:39 pm: > On Fri, 01 Aug 2014, Austin Clements 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. > > I think this is good for now. > > What do you think about adding notmuch_database_get_features(), and > printing that? Mark had a similar comment, so here's my reply: id:20140727162426.GF13893 at mit.edu I'm happy with adding more transparency around this, though I'd prefer to do it as follow-up to avoid expanding this series and because I'm pretty sure adding something like notmuch_database_get_features wouldn't require any non-trivial changes to the stuff in this series. > BR, > Jani.
[PATCH v3 03/13] new: Don't report version after upgrade
On Fri, 01 Aug 2014, Austin Clements 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.
I think this is good for now.
What do you think about adding notmuch_database_get_features(), and
printing that?
BR,
Jani.
> ---
> 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,
> _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"
> --
> 2.0.0
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 03/13] new: Don't report version after upgrade
On Fri, 01 Aug 2014, Austin Clements amdra...@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. I think this is good for now. What do you think about adding notmuch_database_get_features(), and printing that? BR, Jani. --- 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 -- 2.0.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 03/13] new: Don't report version after upgrade
Quoth Jani Nikula on Aug 23 at 6:39 pm: On Fri, 01 Aug 2014, Austin Clements amdra...@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. I think this is good for now. What do you think about adding notmuch_database_get_features(), and printing that? Mark had a similar comment, so here's my reply: id:20140727162426.gf13...@mit.edu I'm happy with adding more transparency around this, though I'd prefer to do it as follow-up to avoid expanding this series and because I'm pretty sure adding something like notmuch_database_get_features wouldn't require any non-trivial changes to the stuff in this series. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3 03/13] new: Don't report version after upgrade
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.
---
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,
_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"
--
2.0.0
[PATCH v3 03/13] new: Don't report version after upgrade
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. --- 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 -- 2.0.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
