Answers:
如果您将同一Web应用程序转售给多个客户，则绝对应该对其进行版本控制。
如果这是一个只安装在一个位置的网站，那么需求就不那么迫切了，但仍然可能不会受到伤害。您也不太会遇到时区问题。诊断库版本1.0.2.25中的问题比查找2010年11月3日上午11:15创建的库要好得多
如果您可以在应用程序的DLL上自动执行版本号，则不会有任何问题。这将帮助您跟踪版本。
通常，Web应用程序仅在托管它的一个位置发布，因此它不如桌面应用程序重要。如果适用，它可以帮助回滚，错误跟踪（即该版本是哪个版本）以及跟踪开发服务器，登台服务器和生产服务器之间的差异。
我会考虑使其自动化-这是一种您可以设置一次并在需要时使用它的东西。
我说，对于琐碎的Web应用程序，您应该对其进行版本控制。这里有两个稍微不同的概念在起作用：
无论哪种情况，我都认为文件应具有单独的版本（或修订）编号。理想情况下，这将由版本控制系统自动处理。正如其他人所说的那样，引用文件的版本号比引用日期和时间要容易得多。
如果您有（或可能有）多个实时安装的应用程序，则应将其整体版本化。如果您有单独的开发环境和测试环境（这可能也是应该的），那么这也是一个好习惯。每个应用程序（或发行版）版本号是指特定版本号的单个文件的集合。尽管处理所有这些都是额外的负担，但签出特定版本要比使用特定修订版号的单个文件容易。
这使我想到了语言学的一个概念。有人说，如果您无法用某种语言表达某些内容，就无法考虑（用该种语言）。我想到了德语单词“ Schadenfreude”。通过引用该词来思考（和说出）“由于别人的不幸而感到喜悦”的概念要比定义它容易得多。这就是该单词开始在英语中流行的原因。
同样，版本号使在特定状态下更易于说（和思考）应用程序及其文件。如果您是一个人的团队，只处理一个应用程序，那么这可能不会有太大的不同。但是，随着事情变得越来越复杂，最好使用这些标签。
您应该使用来自构建服务器的构建ID对Web应用程序进行版本控制，并将该ID包含在所有错误报告中。
如果您必须修复在生产中当前不存在的较旧版本上报告的错误，这将使您及时返回。
从您的问题很明显，您已经想到了一个简单的 Web应用程序
仅可通过Web GUI访问，而不能通过Web（-service）API访问。如果您有用户使用API访问该应用程序，则需要对其进行版本控制。如果更改API，则会破坏客户端，因此您需要同时维护不同版本的API。
当时只有一个实例在运行。即使您只有Web管理员，如果您有更多安装，您也需要知道哪个客户正在运行哪个版本。
具有可接受的停机时间以升级实时版本。数据库可能是一个巨大的问题。较新版本的重要更改随数据基础结构的更改而变化。如果您当时仅运行一个版本，则可能必须关闭旧版本，升级数据库，然后打开新版本。这导致应用程序停机。根据用户的数量和种类，这是可以接受的。
如果您的Web应用程序由客户端和服务器中的多个模块组成，则应该对每个模块进行版本控制。并且应该为客户端和服务器上的模块版本的每个组合提供唯一的ID，该ID应该出现在所有日志记录和错误消息中。
通过使用该约定，始终可以重新创建Web应用在给定时刻所处的状态。
我认为，由于这些天的Web应用都是使用服务器，客户端和客户端双方的动态语言构建的，因此除非用户重新启动浏览器或手动重新加载页面，否则没有理由重新加载更新的Web应用。
仅应重新加载Web应用程序中的更新部件或模块，而不会影响应用程序的整体状态。
你为什么会问？好吧，通过强制实施，Web应用程序的设计将更加强大，正确并且可能更易于维护。如果Web应用程序始终要求同时进行服务器/客户端更新，则可能构建方式不正确。
是的，您应该对其进行版本控制！并且您的版本控制系统中应该有一个与版本号匹配的标签（例如subversion，git，mercurial等）。
标签允许您返回并进行分支。例如：当前的生产版本存在错误，但是您无法修复它，因为您机器上的代码还没有准备好推出。但是，如果您在RCS中标记了该代码，则可以在该标记处分支并修复生产环境中运行的确切版本的错误。
我个人认为无论如何都应该进行版本控制，但是对特定于网站的Web应用程序进行版本控制的一大好处是，它可以使对静态内容的更改更易于管理。
例如，假设您有一个mysite.css文件，该文件的未来有效期很长（通常希望这样做，以便将其缓存在每个页面的浏览器中）。如果您随后在该文件中更改样式，那么除非您曾经做过一些事情来从缓存中清除该文件，否则没有人曾经去过您的网站。
如果您要对网站进行版本控制，则可以将构建中的所有css引用更改为mysite.css？v = 1234之类的内容，这将使您保留较远的到期日期，而不必担心将来的更改，如在下一个构建中'将为mysite.css？v = 1235。
是的你应该。出于分发原因，此处给出其他答案。
但是我明白了，为什么你问这个问题。Web应用程序方法受成本驱动。它与传统的拆封方法相反，后者的成本包括物理介质，分发，安装，文档的硬拷贝，培训和技术支持。可以排除的任何事物均应排除。