I'm just playing around with the first release of 4.5, which is proving to be a pleasant experience after some frustrating YSOD moments during installation. I was wondering:
(a) what the situation is currently with regards to the status of packages and their compatibility with the latest Umbraco versions (namely 4.1/4.5); and
(b) whether there's a plan in place to tag packages to their compatible Umbraco versions.
At the moment, I'm feeling it's a bit like roulette with the packages on v4.5 as there are no indications that I can see, whether any of the packages on our.umbraco.org are compatible with the latest version or not. I'm a hesitant to install them as I fear that many will break and I'll be spending a lot of time fixing and/or re-installing. Others must share these concerns, or at least will do when the userbase for 4.5 grows I'd imagine?
Am I right in thinking all of the packages in the repository within the developer section of the Umbraco installation have been tested and are working on 4.5?
I could see it being massively beneficial - particularly as we get closer to Umbraco 5 - to include a list of versions in the package upload procedure. It would then obviously be easy to query or filter search results on our.umbraco based on the different versions, which would be increasingly helpful.
As umbraco 4.5 was only released on Thursday, I'd imagin that most developers are currently working on upgrading their packages. 4.5 has quite a few changes that are taking a little time to accomodate so I would say it's a case of giving the devs a little time to get up to speed.
When it comes to flagging versions, I'm sure most package developers will make clear which version a package is suitable for (maybe we should come up with a standard such as a v45 tag?), but I would say that anything that isn't specificaly flagged as being 4.5 compatable may need to be tested before you install it on a live site.
Regarding the package repository in the developer section, again, I would go with the assumption that they have not been fully tested on 4.5 (I know there is an issue with the fam fam fam package causing script errors in IE).
I'm pretty sure most of the major packages will be updated as soon as possible, I'd just ask that you bare with us as we make the transition.
Cheers Matt. Apologies if I've come across as impatient - completely unintended as I'm not even going to be using 4.5 on a production site for a good few months anyway, I was just checking it out and it sprung to mind as a potential sticking point for newcomers. I think partly what sparked my question was that I remember talking to a core member a few months ago who was working on updating the most popular packages to work in Medium Trust. I thought that perhaps the core team may have updated the more popular packages (the ones accessible direclty in the 'developer' section of the UI for example) ready for 4.5.
I personally think tagging packages to versions would be an excellent idea - particularly for newcomers to Umbraco. Think of the situation whereby a complete newcomer hears great things about Umbraco, they download the latest version and install a package from within the UI. The whole thing breaks, and they're left a little confused/frustrated. You and me and anyone else who follows Umbraco closely knows that there's a simple reason for this, but there's no way for the new generations of Umbraco users to know what's going on - they just think it's broken. If there was a tag on all current packages to highlight that they're untested on 4.5 which could be removed or updated by the package developer, this would dissolve that (potentially common?) scenario.
Anyhow, those are my thoughts for what they're worth. V4.5 is great by the way, so thanks again to the core for working so hard on such a great bit of kit.
No problem. appologies if my reply made it sound like I thought you were being impatient =)
I totally agree that we need to make sure everybody is aware on what version a package is built for, as as you mentioned, it would be awefull if a newcomer was put off by unsupported packages with no real idea why they don't work.
It would be cool if the packages area could be updated to flag this in some way, but it might be good to discuss here some interim solutions that everybody can use now to help.
A couple of suggestions from me would be for people to use version tags for all the versions they support (v4021, v45, v41rc) and add a supported version section within the project page.
It may also be worth (more so for the future) creating a new version check package action for the package actions project on codeplex.
What do you think? Any other ideas people could do right now to help?
I'd suggest all packages get flagged as v4021 now and then its up to the developer to go back in and update those flags if they can support v45. That would give us a reasonably safe baseline for moving forward. Should a package not get updated it could also mean that its not being supported/actively developed anymore which can be just as valuable to know.
I still would really LOVE to be able to officially get at individual package info as XML from the package pages without having to hack it via screen scraping.
We're adding this functionality this week, by default all packages will be v4 compatible with the option to mark individual files as v4.5 compatible (with the new schema)
@Peter - what sort of package information are you looking for and what is it for?
I was going to write a package update notifier which would check all your installed packages to see if an update is available. For that to work though I need the package info in the package repos to be in a safe format. Pondered screen scraping but should the HTML ever change it would break all the versions of my installed package.
We pondered a strong standard way of having version numbers, storing version number history (to see just how out of date you are), current version number, package name, release status (alfa/beta which currently gets lumped in with the version name), unique way to get to a individual package page (GUID?). Also would be nice to insist package developers have to put in a note explaining why they changed version number. Trying not be become codeplex or anything but to provide enough to get the job done.
Projects and Umbraco versions
Hi all,
I'm just playing around with the first release of 4.5, which is proving to be a pleasant experience after some frustrating YSOD moments during installation. I was wondering:
(a) what the situation is currently with regards to the status of packages and their compatibility with the latest Umbraco versions (namely 4.1/4.5); and
(b) whether there's a plan in place to tag packages to their compatible Umbraco versions.
At the moment, I'm feeling it's a bit like roulette with the packages on v4.5 as there are no indications that I can see, whether any of the packages on our.umbraco.org are compatible with the latest version or not. I'm a hesitant to install them as I fear that many will break and I'll be spending a lot of time fixing and/or re-installing. Others must share these concerns, or at least will do when the userbase for 4.5 grows I'd imagine?
Am I right in thinking all of the packages in the repository within the developer section of the Umbraco installation have been tested and are working on 4.5?
I could see it being massively beneficial - particularly as we get closer to Umbraco 5 - to include a list of versions in the package upload procedure. It would then obviously be easy to query or filter search results on our.umbraco based on the different versions, which would be increasingly helpful.
Thoughts?
Hi Dan,
As umbraco 4.5 was only released on Thursday, I'd imagin that most developers are currently working on upgrading their packages. 4.5 has quite a few changes that are taking a little time to accomodate so I would say it's a case of giving the devs a little time to get up to speed.
When it comes to flagging versions, I'm sure most package developers will make clear which version a package is suitable for (maybe we should come up with a standard such as a v45 tag?), but I would say that anything that isn't specificaly flagged as being 4.5 compatable may need to be tested before you install it on a live site.
Regarding the package repository in the developer section, again, I would go with the assumption that they have not been fully tested on 4.5 (I know there is an issue with the fam fam fam package causing script errors in IE).
I'm pretty sure most of the major packages will be updated as soon as possible, I'd just ask that you bare with us as we make the transition.
Matt
Cheers Matt. Apologies if I've come across as impatient - completely unintended as I'm not even going to be using 4.5 on a production site for a good few months anyway, I was just checking it out and it sprung to mind as a potential sticking point for newcomers. I think partly what sparked my question was that I remember talking to a core member a few months ago who was working on updating the most popular packages to work in Medium Trust. I thought that perhaps the core team may have updated the more popular packages (the ones accessible direclty in the 'developer' section of the UI for example) ready for 4.5.
I personally think tagging packages to versions would be an excellent idea - particularly for newcomers to Umbraco. Think of the situation whereby a complete newcomer hears great things about Umbraco, they download the latest version and install a package from within the UI. The whole thing breaks, and they're left a little confused/frustrated. You and me and anyone else who follows Umbraco closely knows that there's a simple reason for this, but there's no way for the new generations of Umbraco users to know what's going on - they just think it's broken. If there was a tag on all current packages to highlight that they're untested on 4.5 which could be removed or updated by the package developer, this would dissolve that (potentially common?) scenario.
Anyhow, those are my thoughts for what they're worth. V4.5 is great by the way, so thanks again to the core for working so hard on such a great bit of kit.
Hey Dan,
No problem. appologies if my reply made it sound like I thought you were being impatient =)
I totally agree that we need to make sure everybody is aware on what version a package is built for, as as you mentioned, it would be awefull if a newcomer was put off by unsupported packages with no real idea why they don't work.
It would be cool if the packages area could be updated to flag this in some way, but it might be good to discuss here some interim solutions that everybody can use now to help.
A couple of suggestions from me would be for people to use version tags for all the versions they support (v4021, v45, v41rc) and add a supported version section within the project page.
It may also be worth (more so for the future) creating a new version check package action for the package actions project on codeplex.
What do you think? Any other ideas people could do right now to help?
Matt
I'd suggest all packages get flagged as v4021 now and then its up to the developer to go back in and update those flags if they can support v45. That would give us a reasonably safe baseline for moving forward. Should a package not get updated it could also mean that its not being supported/actively developed anymore which can be just as valuable to know.
I still would really LOVE to be able to officially get at individual package info as XML from the package pages without having to hack it via screen scraping.
Cheers
Pete
We're adding this functionality this week, by default all packages will be v4 compatible with the option to mark individual files as v4.5 compatible (with the new schema)
@Peter - what sort of package information are you looking for and what is it for?
That sounds perfect Per, thanks! It'll help a lot with major releases in future too.
I was going to write a package update notifier which would check all your installed packages to see if an update is available. For that to work though I need the package info in the package repos to be in a safe format. Pondered screen scraping but should the HTML ever change it would break all the versions of my installed package.
We pondered a strong standard way of having version numbers, storing version number history (to see just how out of date you are), current version number, package name, release status (alfa/beta which currently gets lumped in with the version name), unique way to get to a individual package page (GUID?). Also would be nice to insist package developers have to put in a note explaining why they changed version number. Trying not be become codeplex or anything but to provide enough to get the job done.
See our.umbraco.org/forum/ourumb-dev-forum/features/9866-Central-version-update-notifier-for-packages for initial ideas.
Cheers
Pete
is working on a reply...