The problem occurs to me using Perl5 for programming and Dist::Zilla (dzil) for deploying to CPAN. But the question is probably a general one, meaning independent of the programming language.
Problem description
Assuming I'm releasing a new version 0.1 of the module Foo with a new feature called bar. I would like to release it as a trial release (dzil build --trial), to be able the get feedback on the change without forcing it onto unaware users. When I'm doing so using my toolchain, the Changes file will look something like this:
1 Revision history for Foo
2
3 0.1 2019-06-19 17:49:09+02:00 Continent/City (TRIAL RELEASE)
4 - added bar
The packed distribution (for upload to CPAN) is a file like so: Foo-0.1-TRIAL.tar.gz
Until here, everything was easy. But from now on, I'm unsure how to react to upcoming events:
Feedback is positive. No changes needed. Bring the release in production.
How should the new (but unaltered) release look like?
Should I do a release with the same version or count the version up? Should I add a new line to the Changes file (e.g "bring trial 0.1 into production") or alter the existing one (meaning just removing the (TRIAL RELEASE)).
Feedback is negative. Changes needed. Add feature/change baz.
Same questions here. The new change surely needs a mention in Changes. But again: Count version up, or let it be? Make a new entry to Changes or alter the existing one?
This is one of these questions where I feel like: it probably doesn't matter to much, but there must be a "best practice". And in the long term it kind of pays of doing it right.
Question
How should I continue with version numbering and Changes file, after doing a trial release to specifically CPAN?
(General answers, which are independent from Perl and CPAN are also of interest)
My general advice is: if the TRIAL turns out to be a resounding success and there are zero changes aside from releasing the same thing without --trial, you can reuse the version, since at runtime the two tarballs will have identical behavior. If you have to make any changes that may affect users or tests, bump the version. If you're unsure, bump the version -- versions are free. Remember that without a distinct version, other distributions can't distinguish the changes in their dependencies, CPAN clients can't request a specific version easily, etc.
As far as the changelog, it may help that MetaCPAN now includes the changes for any trial releases leading up to the stable release in its changes preview, provided it can parse your changelog and the trial releases are marked as such. (example) So I would just include an entry for each distinct version.
I want to upgrade my existing umbraco version project 4.11.10 to 7.5.4, and i decided to upgrade step by step in incremental manner. When upgrading version 4.11.10 to 6.0.0 using nuget package and replacing old dll files with newer one, i am able to run back end and front end side, but on back end, i am not able to view the list of "content" and list of "document types" from my existing project as well as looks like still it displays ui of back end of older version 4, but when i click on "about us", it displays version 6.0.0 as attached in screenshot, please help me to find out the solution, Thanks :) Check here in attached screenshotCheck here - Content not loading
Upgrading from 4.11 to the newest version of 7 should work, HOWEVER, if you're using custom data types, the chances are that some stuff is going to break, as v7 doesn't use UserControls for DataTypes anymore. Some data types can be straight swapped, some not so much. You should be able to see all the DocTypes and content etc though.
When you've swapped the DataTypes out, you may need to reformat the data to match the new DataTypes so you don't lose any data as well. This is something you'd probably have to do either with the API of directly in the database.
I've written some blog posts on upgrading Umbraco, have a read and see if they help:
http://www.attackmonkey.co.uk/blog/2015/10/upgrading-to-73-part-1-preparation
http://www.attackmonkey.co.uk/blog/2015/10/upgrading-to-73-part-2-the-upgrade
http://www.attackmonkey.co.uk/blog/2015/12/upgrading-to-73-part-3-switching-to-razor
http://skrift.io/articles/archive/umbraco-upgrade-strategies/
I can not find any link related with 2.1.5 from SourceForge. I wonder whether I can still use this version as a third party component in my product.
Any comment would be appreciated very much!
Sure you can. Search the web and you will find that version easily (e.g. here or here) It is a different question however whether you should still use that version. It is quite old and lots of bugs have been fixed and new functionality has been added. So do the following:
check the license restrictions (LGPL vs. AGPL)
if you don't have a problem with a GPL based license then use the latest 5.X version
if you can't use APGL buy a commercial license or use at least version 2.1.7
if you go the 2.1.7 route do some testing - in many cases it will do its job still fine. If not you'll probably have to fix it by yourself
Update: I would now use openPDF which is a maintained fork based on 2.1.7.
When I do "Add Existing Frameworks" in Xcode, I see three versions of libiconv.
libiconv.dylib
libiconv.2.dylib
libiconv.2.4.0.dylib
This link says the latest and greatest is 1.13.1. I don't think it's the same as the numbers above.
Any clues?
From checking the /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0.1/Symbols/usr/lib/ folder, the only one of those that's an actual library is libiconv.2.dylib. Both libiconv.dylib and libiconv.2.4.0.dylib are aliases (ie, symbolic links if you prefer to think in UNIX terms) for libiconv.2.dylib.
So at the minute, it'll make absolutely no odds which you link to. Link to the one that gives you the most acceptable generality. So if you can handle any version of the API, link to libiconv.dylib, if you need the API that goes with version 2 of libiconv then link to libiconv.2.dylib and if you're relying on functionality in 2.4.0 specifically then link to libiconv.2.4.0.dylib. I assume that, as per the way things tend to work in UNIX, Apple may change what's an alias for what or actually supply multiple versions of the dylib in future as compatibility requires. At the moment it's all academic.
From what I can make out from Google, libiconv-1.12 builds to libiconv.2.4.0.dylib. I'm not able to determine the rationale behind that version numbering or where the idea comes from.
What is the best version control system to implement with PowerBuilder 11.5?
If you have examples of how you have did branching/trunk/tags that would be awesome. We have tried to wrap our heads around it a few times and always run into problems because we use shared libraries such as PFC/PFE in multiple applications.
Right now we are only using PBNative, and it sucks.
The Agent SVN is a MS-SCCI Subversion plug-in works with PowerBuilder.
Here is a link that describes how to setup Agent SVN to work with PowerBuilder and Subversion.
We currently use Perforce and it's P4SCC plugin, which works very well. In fact, I'm sure I read somewhere that the guys at Sybase who write PowerBuilder, actually use Perforce themselves.
So, to be fair, let's start out by saying that while you're asking about version control, PBNative is source control. If you compare something that is intended to have more features than just keep two developers from editing the same piece of source, then yes, PBNative will suck. The Madone SL may be an incredible bicycle, but if you're trying to take a couple of laps around an Indy track, it will suck.
"Best" is a pretty subjective word. There are lots of features available in version control and configuration management tools. You can get tons of features, but you'll pay through the nose. StarTeam has some nice features like being able to trace a client change request or bug report all the way through to the changed code, and being able to link in a customized diff tool (which is particularly useful in PB). Then again, if cost is your key criteria rather than features, there are lots of free options that will get the job done. As long as the tool supports the Microsoft SCC interface, you should be OK.
There is a relatively active NNTP newsgroup that focuses on source control with PowerBuilder, which you can also access via the web. You can probably find some already-posted opinions there.
Many years ago I used Starteam to control PB applications. PowerBuilder needless to say is an outdated bear, and it has to export each and every object from its "libraries" into source control.
Currently our legacy PB apps have its libraries saved whole into Subversion, without any support for diff's etc.
We use Visual SourceSafe. We don't use PFC, but we do have libraries that are shared among several projects. Till now, each project was developed separately from the others, and so the shared libraries were duplicated. To have them synchronized, they were all shared at the VSS level. Lately we've reorganized our sources so all projects are near each other, and there's only one instance of the shared libraries.
VSS is definitively not the best source control system, to say the least, but it integrates into PB without the need of any bridges. PB has an inherent problem working with source control, so it probably won't make a very difference working with one instead of the other (at least from the PB point of view).
Now, on a personal note, I'd like to say PB 11.5 is a piece of sh*t. It constantly crashes, full of unbelievable UI nuisance and just brings productivity to its knees. It's probably the worst IDE ever created. Stay away if possible.
FYI: The new PB12 (PB.NET) will integrate with SCC systems so you can easily choose which source control system that you want to use. Since we basically have dropped PBLs (they are now directories) files can be checked in/out individually - even with a plain vanilla editor since files are now normal (unicode) text files.
StarTeam integrates so beautifully with the PB IDE. I used that combination at my previous company (PB9 and ST5.x) for several years. You should be managing your code at the object level - don't log the entire PBL into ST...
If you're having problems with that setup, hit me up offline. phoran at sybase dot com.
We use Merant Version Manager for older projects and TFS for newer work. The only issue we have is that TFS does not support keyword expansion and changing the 'read the flowerbox comments' attitude people have. Some folks are nervous about losing the inline versioning history.
We use StarTeam and have been very pleased with it. It combines bug tracking with version control. Unfortunately though we don't store our files on the object level. We just store the PBL files directly in source control. Anything that supports the SCC interface theoretically should work correctly in PowerBuilder.
PB9: We used PVCS but had stability problems with pbl corruption and also problems co-existing with later versions of Crystal Reports (dll conflict) so now we use PB9 with Dynamsoft's Source Anywhere Standalone. This system is more primitive; it is missing the more advanced features for promotion levels and for pulling out an older milestone version of all objects to make a patch build.
What we are looking for now is something which will allow more advanced "change management", to support promotion levels at the change level (rather than at the object level). Would it be better to use perforce, starteam, or (harvest change manager + HarPB), or something else? Any advice on these combinations would be greatly appreciated.
You can always use Plastic SCM with PowerBuilder through SCC. Plastic is pretty advanced in terms of graphics, tools, replica and so on, so it's always a good choice to keep in mind.