I have an old application that I manage that runs on top of a progress database. I'm trying to gather some information, for various reasons. At a minimum, I need to know when Progress 9.1 and 9.1D were released. I mention these two versions because we are using 9.1D and, I assume, the "D" revision is probably just the fourth iteration in miner updates since the initial release of 9.1.
Optimally, I'd like to find a source-link to a Progress DB change log. However, questions for documentation aren't typically acceptable around here. Instead, I'm asking for the date these versions were released and requesting that you provide a source that I can explore further.
9.1A was 1999, 9.1D was 2002.
9.1E SP04, the very last release of version 9, was released in 2004.
With version 10 the product name changed to "OpenEdge". Which is much easier to google than "progress" ;)
If you actually have a given release of Progress installed you can look in the "version" file. It will tell you what the build date was.
For a general idea: http://www.oehive.org/VersionHistory
Related
Is thegraphpackage still available in Roo? I would like to create graphs with Neo4J but i can't find any recent documentation or examples about the feature.
No, the graph package Neo4j is not available in the current, 1.2.5, release of Roo and history informs us that any promise to restore support should be viewed skeptically
This antiquated exchange suggests, along with 3-4 others dated as recently as one year ago, that there is little ground for hope. Moreover, the GitHub activity charts (Sorry, my SO "reputation" is not adequate to post another link. You'll have to figure this one out without help.) show zero development activity related to Spring Roo during the last month. I didn't dig much deeper but the front page shows essentially no activity in the last six months. That's not a good sign. I did read that a new development partner has just signed on, so maybe things will improve. I'm very new to Roo but I'm finding bug after bug, and problem after problem, many of them outstanding, like the absence of Neo4j, for years. I really like Roo's ideas and design but I'm not sure that I'm willing to bet on its robustness let alone its longevity. I don't seem to be alone. I searched the web and asked here but can't find direct evidence (that is, code that I can examine) that it's being used on real-world projects. Folks pick it up and toy around with it. But if they write more than 40 lines or so of code they don't open their source. (Please understand that I'm no deliberate detractor; I'd be delighted to be proven wrong on this point!)
One of the saddest consequences of not having Neo4j is that one of the three existing Roo books, Getting Started with Roo, takes it on the chin beginning near the end of the first chapter. This is otherwise an outstanding book. But the absence of Neo4j kicks its ongoing-project model right upside the head. I know the labor entailed by writing a book. Josh Long must be severely disappointed.
More generally, it seems that tech authors are being implicitly encouraged to write small chunks of code that stand on their own, so that their book won't be damaged overall by one or two technological changes. Of course, readers then never get to see code of significant size. I don't have a solution to offer but I'm definitely feeling the problem.
Edited: Because at least one passerby is demonstrably incapable of understanding the implications of repeatedly broken promises to restore support for Neo4j "in the next few days" several years ago I have explicitly spelled out the fact that support is not currently available and no credible promise of soon restoration is to be found. Please note that a broken promise to restore support implies that support was not restored and subsequent promises to restore support should be treated with some degree of skepticism. So, those who suppose that this answer is "not useful" would likely benefit from the web site. readingcomprehensionconnection.com. Or perhaps the problem is one of attention deficit, which makes it difficult to read more than a few phrases before forming a necessarily hasty conclusion. In that case, one might consider cutting back on the comic books in favor of some reading material without speech balloons. I suppose that I am not alone in finding it difficult to incorporate speech balloons in my merely textual SO comments. Perhaps a future release of SO will support a communication style more familiar and therefore more to one's liking.
Demonstration that Neo4j Is Currently Absent from the Upcoming Release, 1.2.6
The method of search follows the instructions given in (Long & Mayzak, 2011), apparently by Michael Hunger of Neo Technology, Inc., the company that developed Neo4j.
/_/ |_|\____/\____/ 1.2.6.BUILD-SNAPSHOT [rev 32b413d]
Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER.
roo> project --topLevelPackage org.hagiasmon.gswr --projectName gswr
Created ROOT/pom.xml
Created SRC_MAIN_RESOURCES
Created SRC_MAIN_RESOURCES/log4j.properties
Created SPRING_CONFIG_ROOT
Created SPRING_CONFIG_ROOT/applicationContext.xml
roo> pgp trust -keyId 0x29c2d8fd
You must specify option 'keyId' for this command
roo> pgp trust --keyId 0x29c2d8fd
Added trust for key:
>>>> KEY ID: 0x29C2D8FD <<<<
More Info: http://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=index&search=0x29C2D8FD
Created: 2011-Jan-06 10:48:11 +0000
Fingerprint: 558eb0489fe5500c68fa8a306107f33d29c2d8fd
Algorithm: RSA_GENERAL
User ID: Michael Hunger <Michael.Hunger#jexp.de>
Signed By: Key 0x29C2D8FD (Michael Hunger <Michael.Hunger#jexp.de>)
Subkey ID: 0xDEFB5FB1 [RSA_GENERAL]
roo> addon search graph
0 found, sorted by rank; T = trusted developer; R = Roo 1.2 compatible
ID T R DESCRIPTION -------------------------------------------------------------
--------------------------------------------------------------------------------
[HINT] use 'addon info id --searchResultId ..' to see details about a search result
[HINT] use 'addon install id --searchResultId ..' to install a specific search result, or
[HINT] use 'addon install bundle --bundleSymbolicName TAB' to install a specific add-on version
roo>
P.S. I initiated Facebook correspondence with Josh Long, who along with Michael Hunger, are the two folks driving the Roo - Neo4j interface, as far as I can tell. If he responds, I'll update this comment.
I am new to Plone and trying to learn how to setup and maintain a server. I realize I need to develop a schedule for packing the data. Right now I am just trying to test this using the pack function in the Zope control panel and also the command line (bin/zeopack).
I know in practice I should leave a week's worth of history, but if I pack to 0 days shouldn't I see all edit history disappear? I am not seeing this happen. What am I doing wrong?
You may be confusing the "undo" history with the version history. Packing the database gets rid of old, unused data. That eliminates your ability to undo older transactions.
Version history is not the same. Version history is not considered unused data, and is not eliminated in packs.
If you don't want edit history, turn off versioning.
Why does Flyway use version numbers rather than timestamps?
How is that supposed to work with larger and possibly distributed teams?
Do I have to send and e-mail to all team members announcing that I am now reserving version number xy for me?
What happens if two developers both use the same version number?
What if a lower version number is checked into version control (and executed by the build server on the integration database) after another higher number has already been checked in?
I am used to mybatis-migrations that is closely modeled after the migrations in rails (>=2.1) where timestamps are used instead of version numbers.
Right now I think timestamps make a lot more sense: I don't have to worry about version numbers and out of order migrations are easily detected.
Quite a few questions here. I'll do my best to answer them.
Flyway's versioning system is flexible. It doesn't care whether your version is called 1.0, 20120816115123 or 2012.8.16.11.51.23. You are therefore free to use timestamps if you wish.
Reserving a version number can be a simple as adding your name next to a number on a whiteboard, a sheet of paper or a wiki page.
Flyway will detect multiple migrations with the same version and report an error.
Out of order migration support is currently the #1 requested issue and will be included in the upcoming 1.8 release.
what's your strategy to increase build number?
Most software has a hierarchy of version numbers:
The "marketing" version number (like "Windows 7")
The major version number - usually incremented when there's a major new version that breaks some compatibility with a previous version, adds a major new capability, requires purchasing an upgrade, or more.
The minor version number - upgraded every time there's a bug-fix or minor feature enhancement that's released to the public
The build number - this should be incremented every time any change is made to the program, so that if someone finds a problem in a nightly build or beta-test version, you can identify exactly which version was being tested. This number is often a revision number directly from your version control system like Subversion, or a timestamp, or something similar that makes it easy for you to roll back the code to that version if necessary.
All the dlls must have the same version number for one release.
Build number consists of "MajorVersion.MinorVersion.BuildNumber.Revision", usually I keep the Revision Number to be 0. Only the first 3 numbers are changed.
For every nightly build, BuildNumber will be incremented automatically. I will manually increase majorversion and minorversion if the changes are sufficiently big.
Every checkin should be tagged a version, use the subversion current version as the part of the build exe version.
It's quite reasonable to increase the build number for just every build. This way testers can tell more exactly which build they find a bug in and when it is verified to be fixed.
We have a build number that's incremented on every build (formal or otherwise). We use a CruiseControl.NET labeller for this.
We have a version number that's incremented by hand only on formal releases, and we define that centrally in one of the CC.NET scripts, which are held in source control.
Like everyone says, increment the build number for every build. We set the major/minor numbers by hand when we do a branch, a branch is usually done a few weeks before release, then that branch gets regression tested. Builds done on the branch still get incremented though.
We are approaching the initial release of a new product at our company, and I am trying to determine the best method of managing the versions of all of the different components and cross referencng those components with the marketing department version of our software. For various reasons, marketing has determined that the initial release of our product will be 10.1, however all of the components will initially start out at 1.0.0. Through normal bug fixes and patching and continued development work, the different components will no longer be at the same version number, so when marketing department decides it's time for version 10.2, it might contain 1.1.54, 1.2.32, 1.8.2, etc. Obviously, I could use a simple spreadsheet, but that isn't exactly the most user friendly method, and has issues for our tech support people to cross-reference the component versions (the customer is really only aware of version 10.1, 10.2, etc).
Is there a more "professional" method for this, or is a simple spreadsheet the best option?
The main principle I'd suggest is: Use the simplest scheme you can.
Consider making things easy for yourself, your marketing department, and your users.
When you do a release, increment the major/minor version number, and then stamp that across all your components. So in the 10.1 release, all your assemblies will have version numbers 10.1.xx.yy
Then if you really want to complicate matters with different versions within a release (e.g. for minor patches/updates, different customer variants, or just for internal daily or CI builds), then use the xx.yy fields. (In many cases you can get the compiler to automatically fill these two fields in with the date/time of compilation, for example).
This means you have a meaningful "marketing version" which is actually linked to your code versions (so you and marketing can talk about a particular release without any chance of confusion), and you can add extra information (e.g. build date) if (and only if) needed on the dev side.
edit: P.S. Even if a component doesn't change, rebuild it with the new version number. Trying to track a hundred out-of-sync version numbers is an avoidable nightmare.
At places where I've worked, we'd force the software version number to match the official, public (i.e. Marketing's) release number: if they wanted to ship "10.1" then that's what we'd set the software's version resource to, as part of the release build.
Why not leave all components at their "random" version numbers and create one super tag/label with the marketing version that encompasses all components? This allows you to keep updating the components in-between marketing builds and increment their build versions (without having to go to 10.1.001, 10.1.002 that may be visible to the customer) and also keep track of the marketing build. Also, what happens if you update some components for the next marketing build, but not others? Do you need to build those components just to update the version number?
Depending on your source control system, you should be able to easily create a release with a specified name/version that contains all of these components at different versions.
You should also just need to update one properties file with the marketing build number so it shows on all about screens, splash screens, tool bars, etc. If you don't have such a configuration in place, you may want to move to such a system. This allows for easy changes to the customer visible number while maintaining all component build numbers. Besides, what happens when marketing determines that the next version isn't going to be 10.2, but "Crimson?"