So far, as reported here
-
Versioning (1)
-
Versioning (2)
-
Versioning (3)
-
Versioning (4)
team that do
in-house development and also many other teams have the possibility to adopt practices that
extremely simplify versioning
for the modules (assembly, jar, dll, exe, binaries in general,
excluding executables as web-applications, services and web-services) and
speed-up developments: no need for modules to
- provide support and bug-fixing for previous versions
- deal properly the beta, release candidate and official release cycles
- document release notes and track compatibility breaking changes
- handle friendly version numbers
The practices that permit this enormous simplification are:
- have all the teams access the same source code repository and build and test C.I. environment
- always build getting the last versions of the source code (from the head instead of branches)
- have proper automatic tests coverage on modules and applications and manual testing where needed
- have applications referencing modules code (instead of binary, so to get always the last version of the modules too)
- have teams synchronized time-boxed sprints and releases. Commit only potentially releasable code using feature toggles and latent code pattern