我想在Packagist上发布一个PHP库的分支。然而，由于可能不会做出太大的更改，我们希望使用官方版本号，并对其进行一点修改，以添加我们自己的版本号。
所以最后我们想出了一个版本号的想法，比如v1.1.3-CE.1。然而，有一个问题：这不是一个语义问题。尤其是对于任何地方的composer/packagist，建议使用语义版本控制。但正如您所看到的，它仍然与语义版本号非常相似，但我们滥用了"预发布版本"标签"（通常为alpha、beta或类似）。这就是为什么我想问，如果我们在composer中使用非语义版本号，那么像我们的版本号这样的非语义版本数会产生什么影响？更新过程是否受到影响，例如。？
如果您真的不鼓励我们使用这样的版本号构造，我们也可以为我们的fork使用新版本（从0.1开始），但我们并不真的想这样做。
如果你分叉，你就有了一个新的包。因此，您需要一个新的程序包名称。
不重命名分叉会导致问题。首先，您将发布与原始文件包名称相同的新版本。如果你成功了，这将导致愤怒的用户，但更有可能的是，原始供应商名称在Packagist上受到保护，因此无论你分配哪个版本，你都无法以相同的名称发布fork。
因此，这是一个新的软件包名称，但您可以自由地从您想要的任何版本号开始。请注意，语义版本控制对于"0.x"系列确实有不同的规则，特别是一个小的更新可能会破坏那里的兼容性。这就是为什么Composer的^插入符号运算符的行为不同：^1.2.3允许更新1.99999.99999，但^0.7.1将保持在0.7.x范围内。
不要用一些没有意义的东西来重载稳定性标志（例如，我不知道"CE.1"的意思或应该指示什么）。稳定性标志可以很好地标记不适合公众使用的预发布版本（alpha表示可能会发生不兼容的更改，beta表示兼容的更改；RC表示仅修复错误）。