Watch, Follow, &
Connect with Us
Add Component Template
Batch file target
Compiler Message Window
Open Tools API
Project Explorer(old Object Browser)
Visual Form Inheritance
You are not logged in.
[ Add a report in this area ]
Auto increment *MADE* useless
11/10/2011 7:31:27 PM
Serious / Highly visible problem
4/20/2013 6:23:27 AM
Internal Tracking #:
Resolved in Build:
Voting and Rating
(6 Total Ratings)
5.00 out of 5
This is a follow-on to: 98487 in which Andreas Hausladen very well stated, the function has been *MADE* useless.
Tomohiro Takahashi replied:
"This is why the option is now called "Auto generate build number". The numbers are based on the date time that they where generated. They will increase each time, but not by one."
But WHY!!! Can anyone at Embarcadero provide customer feedback where someone actually requested that you *REMOVE* the "auto-increment" and instead place a "auto-generate a random number based on the time".
It is essentially random, there is no way for you to argue out of that.
A good design would have been:
Auto-generate build number:
X - increment per build
X - use time to generate new number
As a customer, the response by Tomohiro Takahashi is completely unacceptable. It sounds like a programmer being lazy and forcing their will on others, instead of taking the efforts to allow people options while providing new features. Instead of creating a useful new feature your laziness results in bugs.
Please fix this in a patch, especially because I really think you will not be able to provide any substantial amount of data where anyone actually requested to get rid of the increment by one.
Steps to Reproduce:
See report 98487
Manually increment number if you want to keep track of the actual build number.
Teodor Nacu at 11/28/2011 12:56:32 AM
There were some important issues with Version Info but with Update 3, those should be fixed.
I am not sure why "Auto-increment" was replaced with "Auto-generate build number.".
"Auto generate build number" option datetime based should work this way:
- Release number should be the number of days from 2000-01-01.
- Build number should be time in seconds for current day).
Hope this helps.
SDET - IDE, QA RAD Studio
Bengt Elstad at 3/30/2012 9:39:32 AM
The new feature is great.
However, Delphi developers have been mistreated by Borland for many years.
Maybe you should show yourself as different from Borland, and make the Auto-generate an option,
while leaving the "old", but VERY USEFUL, Auto-increment available to those who prefer it?
Jan Derk at 12/12/2011 1:56:25 AM
> Hope this helps.
No, it really does not.
These bug reports are opened because we, your paying customers, have used the autoincrement functionality for over a decade and want it back.
Jim Fleming at 12/9/2011 10:18:58 AM
Please, Teodor, don't leave things as they are -- give us back our auto-increment, as we NEED it. If you need the Autogenerate option, or know of others that need that form of version number generation, then by all means provide it.
But don't break the existing arrangement, because people DO USE IT, and even rely on it, as in our case. Not having it automated means we must substitute an error-prone manual procedure that has recently given us a headache we can do without.
Please give us back our Auto-Increment.
Graham Neden-Watts at 11/28/2011 11:51:53 AM
The old system was not broken - why change it? We made extensive use of the automatic build number incrementing, but we exercise strict manual control over the release number. Now we are unable to do this. Why are we forced to change our working practices?
Jordan Fitzhugh at 12/12/2011 4:23:04 AM
I completely agree. We have used the build number autoincrement feature for years, and see no reason for it to be made unavailable without warning or explanation. This is an important feature that should be returned ASAP.
Cristian Peta at 12/16/2011 7:46:07 AM
Build number is in update 3 the number of seconds of the day.
But it should be divided by 2 because the last second in day is 86399 and we have only 65535 maximum.
Now in update 3 after 18:12:15 the build number starts from 0 and you will think that is newer build.
Kevin McCoy at 1/19/2012 12:07:33 PM
This is terrible. Put it back the way it was. NOW.
This really pisses me off as it is a totally unnecessary and not very useful change. If I need the time-of-build, I need look no further than the EXE file date or some internal resource of my own choosing.
I depend on the version number when doing automated field updates of my products. No, I don't want to manually tweak the build number before each build. If I accidentally forget to bump the build number at 3:00 AM, then my customers get no new automated updates.
If Embarcadero wants to keep it then make it optional.
Alexander Pravdin at 2/3/2012 5:39:53 PM
Support this BUG!!!!!
Return standard autoINCREMENT!!!!!! What trash did you smoked, guys? You silently removed the feature used by most develorers and silently replaced it with something unexplainable! How its possible in sanity???
Instead of this new stupid behavior just make an option to make build number based on SVN revision number! It will be useful!!!
Dmitriy Kuzmitskiy at 2/21/2012 5:18:49 AM
Removing auto-increment was completely stupid. This "auto-generate" option is useless.
Whoever did this should be fired ASAP - (s)he can touch other features as well and break them!
Darian Miller at 2/21/2012 9:29:40 PM
Wow, just wow.
Lee GunSub at 3/9/2012 8:35:20 AM
Auto Increment is required.
Our Product is build same version info...
We cannot migrate from delphi2010 because of this.
Stephen Brown at 3/20/2012 11:31:09 AM
I have been using "auto-increment" build number in my production builds forever and I'm currently doing it manually to allow my automatic update program to work. Please put it back in update 5.
Just because Microsoft does something doesn't mean you have to adopt it, diddn't you guys learn anything from adopting .net in delphi 8 and the lousy microsoft help system!
Ken Pemberton at 4/13/2012 1:15:37 AM
I have to agree with common consensus here. Currently trialing XE2, and this could be a deal-killer, completely breaking the way we manage releases.
PLEASE put it back the way it was? I've yet to see a SINGLE person speak out in favour of it. EVERYBODY hates it. At the very least, PLEASE give us the OPTION of having it the way we like it?
We, the paying customers, find this change unacceptable. All of us. What are you, who wants our money, going to do about it?
Klemen Peterlin at 4/13/2012 4:27:54 AM
Right now we are deciding to invest in upgrade. Playing with XE2 and seeing that this option is broken does not help with decision at all.
Why replace a very useful feature with another without user consent? Why not just add a new one and let user decide which one to use? You do realize that changing build numbering system breaks a lot of programs out there?
Resolving this issue by bringing back old system should be of utter importance if you intend to sell us your product in future.
Stefano Bordoni at 5/10/2012 3:03:50 AM
The real problem with the old 'Auto-generate' is that the XE2 IDE seems to have 2 different sets of VersionInfo data for each configurations (Debug/Release).
This means that they will auto-generated but never be aligned between configurations.
Using the timestamp into the AutoGeneration proccess seems quite a patch for this problem.
Klemen Peterlin at 5/11/2012 12:16:36 AM
Misalignment should occur using "auto-increment build number", however that is not the problem as it still provides us with build-specific version numbers which are incrementing over time. If application update system is based on build number, then leaving old option "as is" would take care of backwards compatibility for us, even if build number is not the same for 32-bit and 64-bit version.
I really do not understand and do not find it acceptable to replace an option widely used in all previous versions of Delphi with solution, which is simply not adequate. Normal solution would be to add new option, but keep supporting older one.
Ilya Surnov at 5/24/2012 4:35:52 AM
I'm also using monotonic increasing sequence to version my programs because it is so much easier to check which version is higher. Why auto-increment was transformed into auto-generate *silently* and without any hesitation in XE2?
Gerhard Sachs at 6/26/2012 12:33:23 PM
Autoincrement the build number was very useful and well accepted by my customers. I can not imagine any reason for dropping a good supporting function.
Please RESTORE THE OLD SYSTEM ASAP, at least as an option.
Stefan Burgardt at 7/22/2012 10:42:15 PM
Please, please, PLEASE return to the old autoincrement or make it at least a parallel option to the current autogenerate. The current autogenerate is highly unusable and extremely annoying and I'm doing hard to understand that even now with XE2 Update 4 this is still not improved after so many customer complaints about it.
N Depred at 8/20/2012 4:02:50 AM
And while at it, please also fix it i can tell it which RES file to update.. its hard to put my own manifest in a project resource without breaking how D2010 increments version numbers for the EXE.
N Depred at 8/27/2012 5:59:18 AM
Assuming this leaked XE3 document http://bbs.2ccc.com/attachments/2012/courage2008_20128992520.pdf is correct.. i quote:
The Version Info page now has three Build Options:
- Auto increment build number has been restored from XE.
- Auto generate build numbr has been retained from XE2.
- Do not change build number has been added.
So it seems this issue has been resolved in XE3. Which is being released as we speak.
Why is this not reflected in this issue? Its still marged as open. It should say "fixed in Delphi XE3". And on that note, what IS the whole point of quality control anyway, then?
Lutz Kutscher at 11/21/2012 4:43:34 AM
So it ist fixed in XE3 - and what about the XE2 users?
Having to pay 500EUR+ for this fix (for users of Professional Edition) does not exactly seem cheap or customer friendly to me!!
I get a feeling that they want us to buy new versions every year instead of supporting the ones we already paid for.
Achim Kalwa at 9/3/2012 6:26:55 AM
It is *not* fixed in XE3.
The option "auto increment build number" is back, yes. But the edit boxes for "release" is still disabled.
I would like to report that as a new bug to XE3, but I can't choose that version (reported as QC #108446)
Mariusz Stefaniak at 12/29/2012 2:25:52 AM
I'm user of XE2 version. I can say, that this is absolute dirty trick to break something and want money (upgrade to XE3) for fixing.
I absolutely want to have this future as fix to XE2 !
Robin Sharphouse at 2/27/2013 6:57:19 AM
Very annoyed by this - was a really useful feature, and I can't possibly see why I'd want to use an auto-generated date and time for build release information, when the rest of the world uses a sequential numbering system.
Who's got the time (or self-discipline) to manually update a build number every time I compile - that's what the "auto" surely means.
Make QA tracking and customer support very difficult as you cant easily just say 'is your build version bigger than X' any more.
I also don't see why I should have to pay to upgrade to XE3 to fix Embarcadero's dumb mistake!
Come on guys, issue a patch!
Paul Holland at 9/19/2013 9:21:46 PM
Disappointing Update 4 was no fix for this. Now getting emails saying upgrade to XE5. Upgrade is such a time consuming job (reinstalling components etc) with no guarantee past issues fixed, that I probably won't bother!
View Your Reports
Server Response from: ETNACODE01
Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.
3rdRail & TurboRuby
Add Content (GetPublished)
Audio & Video
Bugs & Suggestions (QualityCentral)
Registered User Downloads
Add Content (GetPublished)
Bugs & Suggestions (QualityCentral)