A version number is not a passport

Newer is a description

This release audit happened during the beach stretch with my son, when midnight to four a.m. was my only work window. Version labels may not sound like holiday reading, but knowing exactly where to resume is valuable when the next session has a hard boundary. The project needed a reliable account of what was current, what was still being tested, and what had actually earned approval.

August thirteenth was about keeping the release story straight. The current R3 work remained pre-launch, and an audit clarified its scope, the meaning of predecessor versions, and the identity that would need to be certified before launch. These are details that can sound like internal bookkeeping. They become less boring when a changed label starts implying a changed level of permission. A newer version is newer. It is not automatically approved, validated, or ready to act more broadly.

The practical decision was to keep all pre-launch phases inside the current release, use corrected predecessors as baselines, and verify the actual runtime identity before launch. That prevented naming from racing ahead of evidence. UBIKITOS already had enough moving parts without allowing the labels themselves to create extra ambiguity. The day did not need a dramatic new capability to be useful. It needed everyone looking at a result to be talking about the same thing.

The label on the box

A software version is a label attached to a particular state of the work. Ideally, it lets someone recover exactly what was present: the relevant behaviour, configuration, dependencies, and limits. In everyday use, though, version numbers can acquire a promotional role. The next number sounds like an upgrade, and an upgrade sounds like permission to expect more. That expectation may be reasonable eventually, but it still needs to be earned by the changes and their checks.

Imagine two hypothetical demonstrations that both use the same product name. One runs the earlier approved configuration. The other uses a newer experiment with different settings. If their results are placed side by side without those identities, the comparison becomes difficult to interpret. An apparent improvement could come from the changed settings rather than the feature being discussed. An apparent regression could come from a different task set. The names do not resolve the ambiguity unless they lead back to the actual conditions.

The predecessor has to be real

Correcting predecessor logic matters for the same reason. A baseline is supposed to tell us what the new work is being compared with. If the predecessor is misidentified, the comparison can become a story about a system that never existed in that form. This is not merely a documentation inconvenience. It changes the meaning of any claim about improvement, continuity, or regression. Before asking whether the new version is better, I need to know what “the old version” actually refers to.

For a founder, this is another place where fluent summaries can hide a problem. A sentence such as “the latest release improves on the previous generation” sounds complete. It leaves open which release, which generation, which conditions, and which measured behaviour. Clear identity turns the sentence into something that can be checked. It also makes disagreements more productive. Instead of arguing about the product in general, people can identify the exact states they are comparing and the question the comparison is meant to answer.

Pre-launch work belongs inside pre-launch

The scope decision kept ongoing phases inside R3 rather than treating each new piece of work as a reason to invent a successor. That is useful containment. A release under preparation can accumulate many fixes, tests, and refinements without becoming a sequence of implied launches. Otherwise, the naming system starts creating a false sense of distance travelled. The project appears to have moved through several generations while the original launch conditions are still unresolved.

This does not mean every release must be frozen indefinitely. It means the boundary should reflect the work’s actual status. A pre-launch fix can be an important improvement within the same unfinished release. It does not need a grander identity to matter. That framing also helps the founder keep attention on the remaining conditions for launch. The task is to close those conditions, not to escape them by moving the conversation to a newer-sounding label. The finish line should not move whenever the vocabulary does.

What is actually running?

The runtime identity question brings the discussion out of documents and into the working system. It is possible to review one state of the code while another state is the one actually executing. Configuration can differ. A process can remain on an older version. A test can exercise a component that is not the component serving the real workflow. These are general examples of why a release claim needs to connect to what is running, not just what was prepared.

For UBIKITOS, certifying actual runtime identity before launch was part of preserving that connection. A useful result should be attached to the system that produced it. A useful approval should refer to the system that will act under it. If those identities drift apart, the paperwork can remain perfectly tidy while the operational meaning changes. The point is not to collect identifiers for their own sake. It is to prevent a correct decision about one thing from being silently applied to a different thing.

This is also a communication problem

People outside a software project should not need to understand an internal version family to understand what the product can do. That places an extra responsibility on the builder. The internal labels need enough precision to support reliable work, while the public explanation needs plain language about capabilities and limits. “Ready for this bounded use” is often more informative than a release number. “Still being tested” is more informative than a name that merely sounds advanced.

The diary is a useful place to preserve that distinction. Today’s release audit was real work. It made the project easier to reason about and harder to overstate accidentally. It did not turn a pre-launch system into a launched one. A reader should be able to understand both facts without decoding the entire development history. The important story is that the work was being kept within its actual scope while the conditions for a broader claim were still being checked.

Keep the passport desk closed

The next step was to continue the contained release work, compare against the corrected baselines, and verify the identity of the system that would eventually launch. That is a practical sequence. It protects the meaning of past results while making future results easier to interpret. It also prevents a founder from accumulating confidence from a collection of labels that do not all refer to the same operational reality. Clear naming is useful precisely because it supports something more substantial than naming.

August thirteenth did not produce a new passport for UBIKITOS. It checked the details on the existing application. The release was still pre-launch, the predecessor needed to be represented correctly, and the actual running system needed to match the story told about it. Those are small sentences with large consequences. A version number can tell us where to look. It cannot, by itself, tell us that the system has earned permission to go somewhere new.