Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Im trying to find some information about the Cognos analytics but without success.
Im trying to find out what is the latest version of Cognos 11 that is availible and When it was the version released?
How much updates this release have already?
How much bugs were discovered?
Does the upgrade from Cognos 10 to 11 is smooth?
Thanks alot
While the question appears a bit broad, I will try to answer the parts of the question I can understand and, hopefully, it will assist the OP.
These are the approximate release dates for the Cognos Analytics 11 that have been released as of the time of this post:
11.0.0: December 23, 2015
11.0.1: March 29, 2016
11.0.2: May 6, 2016
Interestingly, while the 11.0.1 and 11.0.2 releases are seeming to include fixes only, IBM does not appear to be using Fix Packs in the same way as prior releases of Cognos BI. These are full releases that install and upgrade in the same way as if you were upgrading from BI 10.2.1 to 10.2.2 . There have been at least two interim fixes (IF) released as well, one for 11.0.0 and one for 11.0.2, both related to security, if I recall correctly.
While I don't think there is any official statistic on how many bugs were discovered, fix lists can be found for the released versions here:
11.0.0
11.0.1
11.0.2
The upgrade process from Cognos 10 to 11 is smooth in the sense that the overall process is similar to upgrades in past releases. There are some architectural changes for multi-node environments that change the process for installing subsequent nodes. That said, there are some very important deprecations and feature changes/removals that you will want to learn about, not to mention the new navigation, authoring, and content consumption interfaces.
There are a lot of facets to the release that need considering for any production upgrade -- I would definitely jump into the documentation and, assuming you are a current customer, set up a sandbox to start testing functionality before I made any hard plans for moving a production system forward. If you want more very high level feature discussion, a quick Google search for "Cognos 11 new features" or similar will give you a lot of helpful information.
To follow the announcements on the latest releases, you can subscribe to the IBM Analytics blog:
https://www.ibm.com/communities/analytics/cognos-analytics/blog/
or periodically check the product page:
https://www.ibm.com/analytics/us/en/technology/products/cognos-analytics/
For bug fixes, you should refer to the product release notes:
http://www-01.ibm.com/support/docview.wss?uid=swg27047187
, though the list of bugs seem to be less granular than what you would normally see from other IBM products. The list of bugs does not seem to be broken down by fix pack either.
I do not think the upgrade is a smooth one, since it is not an in-place upgrade like you would have from, let's say, 11.0.1 to 11.0.6. I also could not find a clear statement about the upgrade from 10.x in the installation guide, so it is unclear (for me, as of now) whether the process entails the usual backup of the content manager database from original version and restore the backup image to a new database to be used by the new version
I tried exporting the contents from the 10.x installation via Cognos Admin console and then importing it into the 11.0x release, but 3 out of 5 of my reports simply hang on launch even after performing a report upgrade operation via Admin console.
Related
We are planning to migrate our old legacy code which uses commons-httpclient-3.x to httpclient5.x . But found that its going to be complete rewrite as lot of classes/packages removed.
Tried migrating to httpclient4.x , seems to be having lesser changes compared to 5.x migration.
But want to know the support plan for 4.x and 5.x from apache/community. As per maven repo, last release on
4.x was on Oct - 2020 where as 5.x was Jan - 2022
Can i expect fixes/code changes in 4.x for the next 4/5 years atleast if i use it instead of 5.x?
Please share if anyone has idea on this.
I posted the same in apache httpclients forum. I got replies.
Reply from 'Oleg' (one of active members in apache httpclient community)
Both branches will continue to be supported, especially 5.1 and 5.2.
The reason for last releases being so far in the past is simply we have
not been getting that many bug reports and there have been no major bug
fixes that would warrant an immediate release.
5.1 and 5.2 releases though can be expected soon.
Can i expect fixes/code changes in 4.x for the next 4/5 years atleast if i use it instead of 5.x?
We are all volunteers here. No one is gets paid for providing
HttpClient support. We can all go away any time. That is the whole
support plan.
One thing I can guarantee however that there will be no feature
development for 4.5 any more. We will likely be doing fixes for severe
and security issues in 4.5 going forward.
Reply from Michael Osipov
At some point in time we need to decide when to cut off 4.x. I don't see
a reason to keep this branch alive for the next five years. Given that
very little work on this project it would make sense to reduce the
amount of supported branches.
Reply from Gary Gregory
The sooner the better for a 4.x cut off IMO. There is a lot of complex code
in total for versions 3, 4, 5, and very limited human resources.
In Short: We can safely migrate to 5.x. I guess this answers for many developers who are looking for an answer like me.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I tried to learn it from wiki Software Versioning control , but I could't understand very well. I know the last numbers means that many bugs fixed and I already got something from wiki.
but what is the main difference between the versions of app, like 1.2.1 and 2.4.5 ? is there any source for quick explanation? When I update my app on play store, how should I choose version? if I change API should I change the last digits of version numbers from 1.1.2 to 1.1.3 or I must change the first number like 1.1.2 to the 2.1.2?
Thanks.
Semantic Versioning (Major.Minor.Build)
The answer depends on the development team's choice of a versioning scheme. The most common scheme in my experience is the Semantic Versioning scheme in which the three numbers have a semantic value attached to them.
What is the main difference between the versions of app, like 1.2.1 and 2.4.5?
This would indicate that the newer software 2.4.5 has a breaking change and could result in problems for you or any software that consumes that code.
If I change API should I change the last digits of version numbers from 1.1.2 to 1.1.3 or I must change the first number like 1.1.2 to the 2.1.2?
In this case you should choose the version 2.1.2 if the change risks breaking other code that consumes the API, and you should choose 1.1.2 if your change includes something that adds to the API but does not take away from the functionality or interface of the API.
When I update my app on play store, how should I choose version?
Choose what makes sense to you or your team. Sometimes if it controlled by the platform you may not be able to choose, but lean on the side of conforming to the environment you are put in. Meaning follow the versioning conventions of the platform you are developing for.
Major Version
The first number in the sequence (1.x.x) is the major version and this semantically means that the software has a breaking change that could affect any other software that depends on it. For example, you could have an API that completely changes the URI path in an upgraded version from 1.x.x to 2.x.x.
Minor Version
Minor versions are changes to the code that do not reflect breaking changes, but are significant enough to warrant a version increase. More often then not this includes additions to the code that add functionality and does not break it. So if you added a new endpoint to an existing API and kept all other endpoints the same then the API's version could be increased from x.1.x to x.2.x.
Bug/Build Version
The last number in the scheme stands for the bug/build version depending on how you want to look at it. In teams like mine we use the third number to automatically increase the version for every push to our CI/CD pipeline that pushes a version artifact to our repository. This also could be used for bug fixes and hot fixes that come up in the lifecycle of your application. For example, x.x.1 to x.x.2.
Leaving Thoughts
This is not the only versioning scheme out there, and not the last one to be invented. However, this scheme seems to have traction in the industry at the movement and is worth learning. Plus, it enables some cool automation tricks on your CI/CD pipeline when you have meaning behind version numbers and commit standards that align with them. (Conventional Commits)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
The ADO.NET implementation of the .NET framework 2.0 beta 1 included a writeable resultset which was removed in the beta 2. The obvious reasons for this is that it would hog server resources to keep updateable cursors open on the server. However, this would be useful when used correctly; specifically when updating or inserting large numbers of records.
I'm aware of the bulk copy api now available, but there are still many uses for a writeable resultset, so I am interested in researching how it was implemented in beta 1, to determine the feasibility of re-implementing this in a new library.
I'm interested in hearing suggestions on how to do something similar (create a writable resultset) or how to research this further, with or without access to the old framework.
Or, is there a way I can obtain the old framework so I can look into seeing how this was done?
The license for .NET 2 beta 1 and beta 2 (any beta, including RC's) has expired many years ago. You cannot legally use it anymore. Even if you find it, you will be violating the law if you use it.
Microsoft's beta licenses are always structured such that they expire when the final gold version ships. They typically give you a grace period to upgrade, but 6 years is well beyond any grace period.
You should update the app to not use the deprecated API from that beta .net framework. Typically, deprecated APIs have equiavalent and often better ways of doing the same thing.
Beta releases are to get feedback (issues etc...) back to the framework team but also for users to get a preview of what is coming so they can update their app. You should avoid depending on a deprecated API for that long from an old beta framework. Betas are by definition in transition ...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I need some experiences concerning the writing of software documentations and user guides.
When I write formal documents like software specifications, every document gets a version number and in the document there is a change history after the table of contents, where you can keep track of the changes made to the document.
If I'm now writing a software documentation or a user guide for an application, and the software has versioning itself, one could get confused with the version number of the document and the product: e.g. application version 1.5, documentation version 1.3.
What's the common way / best practice to write software documentation? Do you keep track of changes to the documents there? If you print a change history - do you show changes to the product and/or the document?
I've encountered this issue at every company for which I've worked that 1) had a significant code base, 2) attempted professional quality documentation, and 3) had separate development and documentation groups.
I have come to agree with Anders, convinced that software and documentation should have different versioning and version control systems. Although similar and having the same target, documentation and code have different lifecycles, which can be fully independent, only being mapped one to the other at release time.
As for generating the documentation with each software build, ask yourself: does that really make sense? Is the documentation historical or is it prescriptive? Any documentation that is generated with each build better have the tools in place to do it. Currently, that only works for API documentation and there are Doxygen-/Javadoc-style tools to support it. That is likely to never be doable for User's Guides and Installation Guides because they are context sensitive.
The need for different version control systems holds, particularly, for the newer structured documentation methodologies. Structured documentation needs to be managed at a much finer level of granularity than source code to be able to efficiently handle something even as seemingly simple as rebranding; usually managed at either the paragraph, sentence, or word level, unlike the file level, which is sufficient for source code. Further, it is generally economical for document elements to be shared among multiple products or departments (engineering, marketing, ...). And, for this level of documentation sophistication, only a content management system is sufficient for tracking content and managing change; the CVS-/SVN-/Perforce-/Clearcase-style SCCSs are abysmally inadequate for managing real-world documentation. Using different version management tools ensures different version numbers for documentation and software.
Documentation may even have a higher rate of change than software when the need for handling typos, grammar errors, and corporate style changes is considered.
Separating documentation and development processes reduces dependencies, which is the fundamental metric needed for producing a quality product. Further, late binding is desirable to best accommodate the rapid rate of change and unpredictable events like late feature additions or deletions. Only at the moment of final (or alpha-/beta release) should the documentation version be mapped to the software version. But, I agree with High-Performance Mark that the end user shouldn't see different version numbers. The documentation version number does not need to appear on the document. That number can, within the documentation process, be maintained and hidden from the public.
The only time that software and documentation versioning can be maintained in lockstep is when documentation is a fully-integrated part of the development process. Over the last 30 years, I've seen this becoming less and less the case because there is less formal, upfront design than there used to be, relying, instead, on an iterative, quick-prototyping approach to software development. The original well-intentioned notions of having documentation drive software development have mostly been put aside but the new methodology also hasn't given us improved documentation or software. Whether the documentation is done upfront or as an afterthought, it's still going to double the time it takes to develop a commercial-quality product.
I think that the documentation and the software are different items, which each have different version numbers. You want to be able to update the documentation without having to update the software number. I would have named it something like:
System Documentation for productX 1.3
Documentation revision 1.7
By clearly including both the software version and the document version in the same place there shouldn't be any confusion.
We tend to use a plain text format for our documentation, mainly LaTeX, and treat it just like source code from a revision point of view: it goes in the repo, we can do diffs and patches, etc. We're not big for change histories in published documents, we can always audit what has gone on if necessary but it rarely is.
As for synchronising code and documentation version numbers, our preferred approach is that v1.1.1 of a document matches v1.1.1 of the software, 3.2.45 matches 3.2.45 and so on. However, in practice we often only have documentation for the first 2 digits (ie 1.1, 3.2) since the third digit is mainly for bug-fixes or performance enhancements. The repo revision number is inserted into the documentation (and in the source code) using svn:keywords should we ever need it.
I'd like to tell you that the same makefile which builds our new version software also builds the new version of the documentation, but we haven't got there yet. We are, however, working on it.
Why don't you just use version control and use that as the automatic document revision? You can have most systems update some text on checkout.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
My team and I need to work on a project whose bugs are filed in Bugzilla, using Mylyn.
Do you know of any tool or plug-in that provides scrum-inspired burndown charts to Bugzilla or Mylyn?
Hopefully, this tool would be free for commercial usage, but we're not closed to commercial tools.
Update: 4 hours of research allowed me to find very few free tools. Looks like bugzilla isn't popular in agile teams! And obviously, it's not the best fit.
The Songbird project made a really good job of documenting how they customized their Bugzilla instance and developed tools to automatically generate daily reports, including burndown charts. They released their set of tools as ruby open-source code under the MIT license. Very interesting stuff, especially since it comes from a high-profile, important community project.
There's Scrum Vision:
free
open source in very active development
for mylyn
publishes burndown chart to a Google Spreadsheet
We think of this as the last resort option, because of the charts being generated offsite.
There's also TargetProcess:
commercial
free for up to 5 persons, self-hosted (need a Windows server)
integrates with Bugzilla and JIRA:
Bugzilla synchronization is automatic, one-way (read-only)
JIRA synchronization is automatic, two-way
Subversion, Selenium, and more
And there's VersionOne:
supposedly the most used commercial tool
integrates with Bugzilla, JIRA, Subversion, Fitnesse and more
There's also a really nice features list (PDF).
There's also Yoxel:
commercial open-source
integrates with Bugzilla and others
not sure if burndown charts are part of the free open-source offering
UI and UX made it really hard to find burndown charts. Or maybe because the demo data wasn't setup to make them work, because I've definitely seen line charts, just no burndown-looking one.
It wasn't easy to find out that ScrumWorks Pro features burndown charts, but on second look, it does:
commercial
price undisclosed (contact the company for a quote!)
Pro integrates with Bugzilla and JIRA
synchronization is manual: import or update-from-reimport
synchronization is one-way: bugs/issues are read-only in the software
I also found Rally Enterprise Edition.
commercial
EE integrates with:
Bugzilla and JIRA:
Bugzilla synchronization is automatic, two-way
JIRA synchronization is manual, two-way
Mylyn & TaskTop
Subversion, Fitnesse, Hudson, Ant, and much more
Free for commercial use
Online
Simple
Have a look:
http://www.burndown-charts.com/teams/dreamteam/sprints/prototype-x
Oh they also support teams in different time zones and openID.