Recently (a week or two ago), i added ascii-art-to-unicode.el to GNU
ELPA as package ‘ascii-art-to-unicode’.  This was accomplished in one
commit, having previously made the adaptations to ELPA from the previous
released version locally.  After a day or so, i saw that the package
appears in the "list of packages" page, with the proper version number.
Cool.

Now, i would like to add gnugo.el and some related files as package
‘gnugo’, but this time, i'd like to do the adaptations publicly, over
several commits.  In this case, it would be unseemly to have the package
appear in the list of packages during this phase.  I understand that the
ELPA maintenance scripts trigger on change of ‘Version’ header, from
this packages/README excerpt:

  This cron job only creates a new package when the "version" (as
  specified in the foo-pkg.el or in the "Version:" header) of a package
  is modified.  This means that you can safely work on the next version
  here without worrying about the unstable code making it to GNU ELPA,
  and simply update the "version" when you want to release the new code.

But it's not clear to me that the initial commit, where ‘Version’ makes
the transition from non-existent to existing-but-not-ready-yet, won't
trigger the new-package process.  In sum, steady-state OKAY, boundary
condition behavior HMMM.  So, given

  A -- B -- C -- D

where A through C have the "work in progress" version and D has the
"fully adapted" version, what must i do to ensure that only D triggers
the "new package" process, and not A through C?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil