(FR) Build number and release date should be obtained automatically

[Daniel Kulesz]

We should find a way to automatically integrate the current build number from the VCS (i.e. using "bzr revno", but a solution which does not depend on the bzr binary would be even better) and the current date (should be rather simple) dynamically into the build script, that is, without relying on resources/appResources.properties. This would simplify bug tracking from development builds. Since these strings are currently updated rather rarely, "Help->About" often reports incorrect information.

[Johannes Wettinger (jojow)]

We could use the current timestamp (e.g. number of seconds or hours since 2000-01-01) as build number instead of using the revision number. What do you think about this approach?

[Daniel Kulesz (kuleszdl)]

I am not very convinced about this approach, as it doesn't really help traceability. If I encounter a certain bug in some version I am running, I want to be sure, which version I was really running - not when it was built. Having the date/timestamp might be a nice bonus, but it's not a supplement for the revision number and (what I forgot) the branch name.

[Daniel Kulesz (kuleszdl)]

Sorry - I meant "replacement" not "supplement". Indeed the date/timestamp would be a nice supplement, but not a good replacement for the revision number and branch.

[Johannes Wettinger (jojow)]

Yeah, that's right. But I don't think there's a direct way to find the current revision number independently from the repository software binaries (svn, bzr etc.).

Another approach could be (defensively) to try to get the current revision number from the repository. If this is not possible (e.g. in case the binary is not available), then just add '1' to the current build number.

[Holger Röder (roederhr)]

Tool independence is nice to have, but in this case, I think we can stick to bazaar and use the revision numbers it provides. If we ever change our configuration management system, we'll know that revisions 1 to X can be found in the 'old' bzr repository.

But how can we make sure that a running RevAger instance knows the revision number it was built from? Updating the appResources.properties file during the build process might be a workaround, e.g. by adding the following commands to our build script (exec + propertyfile in 'init' target):

<property name="propertiesfile" value="build/neos/resi/resources/appResources.properties" />
...
<exec executable="/usr/local/bin/bzr" outputproperty="revno">
 <arg value="revno" />
</exec>
<propertyfile file="${propertiesfile}" comment="set revision number in properties file">
  <entry key="appBuild" value="${revno}"/>
</propertyfile>

However, this assumes that bzr is installed - which might not be the case if a user downloaded RevAger.src.zip from out website. :) We'd also have to deal with different binary locations etc. - argh! :)

Any other ideas?

[Daniel Kulesz (kuleszdl)]

Regarding the location of the executable: Propably using

which `bzr`

should work, at least on UNIX-like systems. Since we have this "isMacOS", "isLinux" etc. variables, we can propably incorporate them in here. For Windows, we need a different solution of course.

The problem with the requirement regarding bazaar is the same as the problem with the requirement regarding hdiutil - both are dependencies, we don't want to have in the future, although they seem to be a working, temporary solution.

Regarding the problem with the "source only, no bazaar" distribution. I think, we should split our Ant tasks apart, so that the bazaar-dependent tasks are run BEFORE the tasks which need the version number. So for example we currently call the tasks in the following order (I didn't double-check this):

init -> compile -> dist -> release
init -> source

At the moment, the bzr-dependent stuff is handled in "dist" or "release", which makes the source distribution difficult. The goal is to have a "source" which is compileable and "release"able without bzr. To accomplish this, I guess we need to split apart "init" into two tasks, one with the bzr-dependency and one without. Then, we could have the following order:

bzrinit -> init1 -> source -> init2 -> dist -> release

Now, when I downloada source only distribution, it is already in the "source" state. So when I call "dist" or "release", it starts off with init2, not with bzrinit. I guess there is some more state-modeling work necessary to find a really good solution for this.

[Johannes Wettinger (jojow)]

I think we can just use the 'bzr' command, i.e. '<exec executable="bzr" outputproperty="revno">'. This should be a platform-independet solution because after you installed bazaar, the binaries will be registered in the environment path variable automatically. IMHO we should not introduce distinctions between different platforms where it is not necessarily needed. ;-)

I like Daniel's suggestion to find a way to split the bazaar-dependent stuff from the dist & release targets. Maybe we can just add a target called 'bzr-newrelease' which updates the build number inside the appResources.properties file and after that calls the 'release' target.
Inside the 'release' target we should update the date inside the appResources.properties file as well.

Besides of that, I suggest to insert a new property called 'vcsRepository' into the appResources.properties file. This property in our case holds the bazaar branch URL like 'lp:revager/1.2', so we can include this information in the About screen.

What do you think about these suggestions?

[Daniel Kulesz (kuleszdl)]

Sounds fine! I thought about just leaving bzr in there as binary as well - I was not sure if it works, but if it does, it's much better than the "which `bzr`" approach I proposed.

Your proposal with the 'bzr-newrelease' target is exactly what I was thniking about, too. I think it's really worth a try doing it this way.

Your third suggestion with including the branch is also great! So I guess we agree in all these points now :-)

[Johannes Wettinger (jojow)]

I suggest to handle this bug report as a "usual" bug (not a FR) because on the one side this is not a new feature for the application itself, on the other side I don't think it makes so much sense to create a blueprint for this guy. ;-) What's your opinion?

[Daniel Kulesz (kuleszdl)]

The basic nature of this issue is actually a bug, namely the outdated version number in the help->about box as initially stated. Although the "quick fix" would be to just update the string, we are of course looking for a robust solution for this problem for the near future.

But why should we omit creating a blueprint for this? Or asking more in general: Should blueprints be strictly tied to functional requirements by the "customer" only?

[Johannes Wettinger (jojow)]

Ok, from my side we can also write a simple blueprint for this kind of feature requests. What's the opinion of the other developers here?

[Davide Casciato (casciade)]

Johannes, i agree with you wholeheartedly ;)