4.4.2. Informal¶
Before we study what are formal ways to version your product, let’s explore some ways and in-formal ways to version them. This is an easy, disciplined and manageable way, but not the best way for software. But something is better than nothing, hence better to use this in-formal way of versioning, rather than not doing any versioning at all.
4.4.2.1. Just Increment¶
Just increment a number. First iteration would be my-logo-1.jpeg, and then make my-logo-2.jpeg and then my-logo-3.jpeg and so on.
It would be a good idea to keep a small text file next to that logo to list all changes that you made in each version. And if possible try to list why you made that change.
If you are using some Configuration Management system, then the entry in your change log file would be very similar to that in your Commit Messages / Change Messages.
Sometimes, it may be an issue if you have to remember what was the last number that you used for a release. Other times, it may also be a concern that you don’t want to communicate how many iterations have gone in between. For that case, you can use Current Date as explained in next section.
4.4.2.2. Using Current Date¶
If your iteration takes days to finish, you can use YYYY.MM.DD as a versioning scheme.
YYYYis current year in 4 digitsMMis current month in 2 digits. So February is written as 02.DDis current day in 2 digits. The date 7 is written as 07.
e.g. my-logo-2022.02.01.jpeg, and next revision few days later could be my-logo-2022.02.05.jpeg. This way you have an automated numbering scheme.
The scheme YYYY.MM.DD is very important because it guarantees incremental order over course of months. Also, internationally it’s important to remember that America, Canada and few other countries use MM.DD.YYYY format, and many other countries use DD.MM.YYYY format. YYYY.MM.DD is standardized according to ISO 8601, YYYY.MM.DD is standardized. https://en.wikipedia.org/wiki/Date_format_by_country is an interesting read to understand how diverse the world is when choosing which date format to use.
Choosing DD.MM.YY or MM.DD.YY is not recommended because it can confuse few users what exactly 02.05.22 is? Is it 2 nd May or Feb the 5:sup:th?
DD.MM.YYYY (or MM.DD.YYYY) is also not recommended because sorting your documents based on this scheme by file names would club all iterations on a particular date or month together. e.g. this is a potential sorting.
DD.MM.YYYYformat:my-logo-02.02.2020.jpeg
my-logo-02.12.2021.jpeg
my-logo-03.10.2021.jpeg
my-logo-04.04.2020.jpeg
my-logo-04.12.2021.jpeg
my-logo-07.10.2020.jpeg
As you can see, files of 2020/2021 are just jumbled and mixed. Similar effect would be seen on MM.DD.YYYY format as well. On the contrary as you can see below, YYYY.MM.DD gives a very good sorting.
YYYY.MM.DDformat:my-logo-2020.02.02.jpeg
my-logo-2020.04.04.jpeg
my-logo-2020.10.07.jpeg
my-logo-2021.10.03.jpeg
my-logo-2021.12.02.jpeg
my-logo-2021.12.04.jpeg
4.4.2.3. What if you have to release more than once in a day?¶
For such cases, you can upfront use a 4 part scheme, YYYY.MM.DD.NN
YYYY.MM.DD.NNformat:my-logo-2021.10.03.00.jpeg
my-logo-2021.12.02.00.jpeg
my-logo-2021.12.02.01.jpeg
Here, the last NN is mostly kept as 00. But only if you have to make a new delivery on same day, just increment that to 01, and keep incrementing if needed. In above example, 2 releases were made on 2nd December 2021, and both are handled.
4.4.2.4. Much more detailed versioning, Date and Time¶
Just as we used Date, we can also use both date and time to uniquely identify the version number. YYYY.MM.DD.hh or YYYY.MM.DD.hh.mm or YYYY.MM.DD.hh.mm.ss or YYYY.MM.DDhh
Just like before,
YYYYis current year in 4 digitsMMis current month in 2 digits. So February is written as 02.DDis current day in 2 digits. The date 7 is written as 07.
And,
hhis hour in 2 digits, in 24-hour format. So 3 PM is written as 15.mmis minutes in 2 digitsssis seconds in 2 digits