Unless you are in the enterprise space and your customers require significant customization of their app and you can charge them accordingly, I'd avoid this. As you're discovering, this is the tip of the iceberg of a product management nightmare. One of the reasons SaaS has become so popular is that it is very difficult to manage different people on different versions, and it's hard to get people to upgrade.
Having done this a few times (I'm a product manager by background, not an engineer, so I probably feel the pain nearly as bad as the engineers having to implement), I would suggest having configurable parameters. Often you can charge extra money for this type of configuration. That is, the base price comes with little to no customization, and higher tiers allow CSS customization, branding, etc. See JobScore.com for an example. A good reason to charge money for this is that smaller companies don't care and won't pay, but larger companies want the feature and won't care as much about the cost. Getting this sort of price premium is critical for a successful SaaS product: Most SaaS companies make 80% of their revenues from the "enterprise" version of their product, so you need to price accordingly. If your top tier is $99/mo and WalMart signs up and uses it for $99/mo across their entire company, you're leaving a lot on the table.
Anyway, back to the original question: don't allow different versions, that could literally kill your company. Instead, offer configurations/variables.
Instead of having parallel customized versions, implement one configurable version accessed by all your clients.
It will give you more trouble to code it but when you get your app up and running you will only have to worry about what are your new needs and not what those new needs will break.
Here is a good article I found on software services versioning best practices and I believe the same applies to your question. It basically describes the two possible options available along with the pros and cons of each one.
Maintain different versions of the software.
Maintain a single baselined version of the software.
While rolling out an enterprise SAAS product, at some point it'll become inevitable that you support multiple versions of your software product(at the risk of losing customers if you do not support such a strategy). There are some benefits to this approach notably one which supports a massive rewrite the of api/services if required while not being bogged down by backward compatibility issues. However it would be imprudent to maintain 200+ versions of the software and thus a balance is needed limiting the number of versions being supported and also having a deprecating strategy to nudge the customers towards the latest version of the product.
发布评论
评论（3）
除非您在企业领域并且您的客户需要对其应用程序进行大量定制并且您可以相应地向他们收费，否则我会避免这种情况。 正如您所发现的，这只是产品管理噩梦的冰山一角。 SaaS 如此流行的原因之一是管理不同的人使用不同的版本非常困难，而且很难让人们升级。
这样做过几次后（我是一名产品经理，而不是工程师，所以我可能感到与工程师必须实施的痛苦一样糟糕），我建议使用可配置的参数。 通常，您可以为此类配置收取额外费用。 也就是说，基本价格几乎没有定制，更高的价格允许 CSS 定制、品牌等。请参阅 JobScore.com 的示例。 对此收费的一个很好的理由是，小公司不在乎也不会付费，但大公司想要这个功能并且不会太在意成本。 获得这种溢价对于成功的 SaaS 产品至关重要：大多数 SaaS 公司 80% 的收入来自其产品的“企业”版本，因此您需要相应地定价。 如果你的顶级服务是 99 美元/月，而沃尔玛注册并在整个公司以 99 美元/月的价格使用它，那么你就留下了很多钱。
不管怎样，回到最初的问题：不允许不同的版本，这实际上可能会毁掉你的公司。 相反，提供配置/变量。
Unless you are in the enterprise space and your customers require significant customization of their app and you can charge them accordingly, I'd avoid this. As you're discovering, this is the tip of the iceberg of a product management nightmare. One of the reasons SaaS has become so popular is that it is very difficult to manage different people on different versions, and it's hard to get people to upgrade.
Having done this a few times (I'm a product manager by background, not an engineer, so I probably feel the pain nearly as bad as the engineers having to implement), I would suggest having configurable parameters. Often you can charge extra money for this type of configuration. That is, the base price comes with little to no customization, and higher tiers allow CSS customization, branding, etc. See JobScore.com for an example. A good reason to charge money for this is that smaller companies don't care and won't pay, but larger companies want the feature and won't care as much about the cost. Getting this sort of price premium is critical for a successful SaaS product: Most SaaS companies make 80% of their revenues from the "enterprise" version of their product, so you need to price accordingly. If your top tier is $99/mo and WalMart signs up and uses it for $99/mo across their entire company, you're leaving a lot on the table.
Anyway, back to the original question: don't allow different versions, that could literally kill your company. Instead, offer configurations/variables.
不要采用并行的自定义版本，而是实施一个可供所有客户端访问的可配置版本。
这会给你编码带来更多麻烦，但是当你启动并运行你的应用程序时，你只需要担心你的新需求是什么，而不用担心这些新需求会破坏什么。
Instead of having parallel customized versions, implement one configurable version accessed by all your clients.
It will give you more trouble to code it but when you get your app up and running you will only have to worry about what are your new needs and not what those new needs will break.
这是我发现的一篇关于软件服务版本控制最佳实践的好文章，我相信这同样适用于您的问题。 它基本上描述了两种可能的选项以及每种选项的优缺点。
https://www.slideshare.net/TorryHarris/soa-serviceversioningbestpractices
推出时对于企业 SAAS 产品，在某些时候，您将不可避免地支持软件产品的多个版本（如果您不支持这样的策略，则可能会面临失去客户的风险）。 这种方法有一些好处，特别是它支持在需要时大规模重写 api/服务，同时不会因向后兼容性问题而陷入困境。 然而，维护 200 多个版本的软件是不明智的，因此需要平衡限制支持的版本数量，并制定弃用策略来推动客户使用最新版本的产品。
Here is a good article I found on software services versioning best practices and I believe the same applies to your question. It basically describes the two possible options available along with the pros and cons of each one.
https://www.slideshare.net/TorryHarris/soa-serviceversioningbestpractices
While rolling out an enterprise SAAS product, at some point it'll become inevitable that you support multiple versions of your software product(at the risk of losing customers if you do not support such a strategy). There are some benefits to this approach notably one which supports a massive rewrite the of api/services if required while not being bogged down by backward compatibility issues. However it would be imprudent to maintain 200+ versions of the software and thus a balance is needed limiting the number of versions being supported and also having a deprecating strategy to nudge the customers towards the latest version of the product.