Hi,
Last October we agreed on a versioning scheme for msysgit and a
few criteria when to go stable [1].

[1] http://article.gmane.org/gmane.comp.version-control.msysgit/899


Today, I updated share/WinGit/HowToRelease.txt  to reflect the
current status.  Here is the relevant section:


We use the following criteria to decide if we go stable.
* features equivalent to official git-#-#-# are available in Git Bash.
    * [DONE] git-gui works if run from Git Bash.
    * [DONE] git-gui works if run from Start Menu.
* [DONE] git and git-gui available from Windows Command Prompt (cmd shell). * server functionality (git-daemon, git-shell, ...) _not_ necessarily
      supported.
    * git-cheetah _not_ needed.


Now that we have resolved the most urgent issues, I think it's
time to further discuss what "feature equivalent" means.

In a mail related to the Git User's Survey 2007 I proposed to
group git's commands into several categories [2].  My idea is
that these groups should reflect typical workflows.  This would
make it easier to discuss the high level tasks git is used for.

[2] http://article.gmane.org/gmane.comp.version-control.git/61815


For msysgit, these grouping could help to make a decision where
to focus our efforts, and how to decide when we'd declare a
msysgit release stable.

Personally, I am only interested in the groups I denoted
"plumbing" and "core porcelain" and would focus exclusively on
commands in these groups (a comprehensive list is not yet
available).  I could imagine having a stable release *without*
mail porcelain, import/export or admin tools.  Users who want
to use commands from these groups would need to work on Unix.

I'd declare a release as stable if all "plumbing" and "core
procelain" commands were supported with features equivalent to
official git (a detailed list needs yet to be defined).  I'd
certainly not exclude a command that is not included in these two
groups if the command works.  However, missing commands would not
be accepted as bugs and the release notes would explicitly state
that only a subset of the official commands is supported by
msysgit.

I believe we should not only focus on the features visible by the
user but also make sure these features are implemented in C.
Migrating stable commands from shell code to C code is accepted
as a good way to ensure interoperability with Windows.
Eventually, we could get rid of all the Unix emulation tools and
I believe this would be a good thing.  So maybe, we should add a
criteria that states that "plumbing" and "core porcelain" should
be implemented in C.

The criteria would be changed as follows:

--- snip ---
We release a stable version if:
    * commands from "plumbing" and "core porcelain" equivalent to
      official git are available in Git Bash and implemented in C.
      (A list of commands would be added here.)
    * [DONE] git-gui works if run from Git Bash.
    * [DONE] git-gui works if run from Start Menu.
    * [DONE] git and git-gui available from Windows Command
      Prompt (cmd shell).
    * other command, such as "mail porcelain", "import/export",
      "admin", "server" are *not* required, though commands from
      these groups may be included.
   * git-cheetah is *not* required.
--- snip ---

What do you think?

[ Side note: it is unlikely that you can talk me into supporting
  more than the core porcelain on Windows; *except* that someone
  pledges to support the msysgit effort by taking responsibility
  for commands that do not belong to the core porcelain. ]

        Steffen






Reply via email to