This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 99537 [details] Proposed patch Setting -Dbuildnumber=... to something that could be interpreted as a number, such as 20100527, is a bad idea; this was the root cause of bug #186755. While the module system does not care, some parts of the build harness treat an integral OpenIDE-Module-Implementation-Version specially: implementation deps are advised to be on numbers, whereas build versions should be opaque strings. If a module specifies an explicit -I-V then that is used in the JAR (and ${buildnumber} is used for OpenIDE-Module-Build-Version), but otherwise (the usual case) ${buildnumber} is used for -I-V. In this case it is undesirable for the -I-V to look numeric. The attached patch prevents you from accidentally passing -Dbuildnumber=20100527190000 or whatever. It cannot be applied yet because RE production builds continue to do this. (The string seems to be passed in from some external script via the environment variable $BUILDNUMBER, so I cannot identify the real source.)
Intentionally assigned to RE - reread last para.
Hello Petr, can you start using 2012-08-22-0300 as build number and then apply the Jesse's patch?
The change of build number will affect installers, QA automatic tests etc. The change have to be discussed with those teams. We will address it a next release.
Speaking for QE : we can start discussion and keep that on radar for 7.3 . Let's move on and tell us what exactly will change and how, we will modify our scripts and start to use new approach in a days.
OK, let's discussion and experiments start. My part is available in the separate branch "new_build_number" in the repository core-main. http://hg.netbeans.org/core-main/rev/90028d5ceccd A new build has been setup for that branch and it currently fails in the installer build section.
So what are the next steps needed on this?
(In reply to comment #6) > So what are the next steps needed on this? jrechtacek should accommodate the installers built at the branch.
(In reply to comment #7) > (In reply to comment #6) > > So what are the next steps needed on this? > > jrechtacek should accommodate the installers built at the branch. I'm looking on it.
http://hg.netbeans.org/core-main/rev/d75dacf8fd60 http://hg.netbeans.org/core-main/rev/d75dacf8fd60 Done on the branch. I'm going to do the merge in the next week.
On account of the change in buildnumber requires changes in setup of some (QE jobs, nbbundles) and because of possible risk with handling impl.dependencies of NetBeans module I propose to do the merge after branching release73.
agreed on waiver
(In reply to comment #11) > agreed on waiver After discussions, it seems QA doesn't want to change the build number format. The issue should be closed as "wontfix".
(In reply to comment #12) > (In reply to comment #11) > > agreed on waiver > > After discussions, it seems QA doesn't want to change the build number format. > The issue should be closed as "wontfix". Petr, we do support this change .. .please postpone decision to 'after 7.3.1' and we can talk about it on next installer i-team.
So, I would prefer to add version into build number, get rid of seconds and change format to something readable by human bodies as well, e.g. : 7.3_2013-05-30_00-55 7.3.1_2013-05-30_00-55 Dev_2013-05-30_00-55 [version]_YYYY-MM-DD_HH-MM
*** Bug 222677 has been marked as a duplicate of this bug. ***
Gentlemen, Why do you need the build time as part of the version number? Why can't you publish a mapping between a version number and the time to the server for internal use? I assume this mapping is used by computers (not humans) and they are more than capable to parse this mapping off the server. The version number should be geared towards human beings, not computers :) I personally prefer: major.minor.build such as 7.3.1, 7.3.2, etc. But this works as well: major.minor.patch.build such as 7.3.1.32, 7.3.1.33, etc. Point being, the version number should be short enough for humans to parse quickly and easy to remember. Once you go beyond four numbers it becomes difficult to parse and remember.
(In reply to comment #16) > Why do you need the build time as part of the version number? Why can't you > publish a mapping between a version number and the time to the server for > internal use? I assume this mapping is used by computers (not humans) and they > are more than capable to parse this mapping off the server. no mappings, keep it self-explanatory
(In reply to comment #17) > (In reply to comment #16) > > Why do you need the build time as part of the version number? Why can't you > > publish a mapping between a version number and the time to the server for > > internal use? I assume this mapping is used by computers (not humans) and they > > are more than capable to parse this mapping off the server. > > no mappings, keep it self-explanatory So why do you need the build time as part of the version number? Why isn't major.minor.patch.build enough?
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > no mappings, keep it self-explanatory > > So why do you need the build time as part of the version number? Why isn't > major.minor.patch.build enough? Because with time it will be clear when exactly it was build.
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #16) > > > no mappings, keep it self-explanatory > > > > So why do you need the build time as part of the version number? Why isn't > > major.minor.patch.build enough? > > Because with time it will be clear when exactly it was build. So if I understand you correctly, you're implying that users prefer a build time to a build number. Meaning: 7.4.0.2013-06-13_10-12 vs 7.4.0.5 I personally prefer the latter because it's easier to read and remember. I don't really care when the build was created, but that's just me. I would point out that the majority of projects in the wild use the latter syntax, and have been doing so for decades now. Lastly, if I wanted to look up when a build was created, it would be sufficient for me to go to netbeans.org and look it up. I personally don't see the need to embed a date into the version number (which is not to say that this information couldn't be available externally).
After the next round of discussions we reached to conclusion, we will not change the format of ${buildnumber}. Rather IZ notification will be improved to show branch name in the notification.
(In reply to comment #21) > After the next round of discussions we reached to conclusion, we will not > change the format of ${buildnumber}. Rather IZ notification will be improved to > show branch name in the notification. How will that help?