This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Robert, please don't delete content of previous state when staging new one. It causes a lot problem when users use older cache of UC catalog.xml which linking to non-existing paths of NBM. I propose to just new patch4 directory and patch3 leave without changes. Is it possible to stage patch3 (http://updates.netbeans.org/netbeans/updates/6.1/uc/final/stable/modules/patch3/) directory again? Thanks
I don't quite understand. Do you mean both: http://updates.netbeans.org/netbeans/updates/6.1/uc/final/stable/modules/patch3/ http://updates.netbeans.org/netbeans/updates/6.1/uc/final/stable/modules/patch4/ should be available at the same time ? That would be quite difficult to achieve - catalog generator is designed to pick modules from all the directories, that means patch3 modules would get included to catalog. Furthermore - how long should be the directory with previous patch kept ? Sounds like for long time, maybe forever. It would double disk space occupied by the UC on the download server with each release of a new patch. So I really hesitate with this solution.
In the case you don't want to left previous patch3 directories, don't add patch number into URL and just simple replace old NBM with new one. It will work as well.
This is not possible - it is requirement from sustaining that download URL is changed with each new patch.
After discussion with Jirka we came to conclusion that the quickest and best solution will be to re-upload patch3 NBMs to sever and keep them there for a little long then a week. Catalog is cached for a week, so to avoid problems with older cache of UC catalog is enough to keep old patch module a little longer that a week.
> Catalog is cached for a week, so to avoid problems with older cache of UC catalog > is enough to keep old patch module a little longer that a week. Keeping two last folders (new one and previous one) there forever (until a new patch is released) is the easiest and the most safe approach.
Ptach3 modules were re-uploaded to server,that should solve the problem. With Tonda we have discussed all the technical details of this issue and we agreed that it is really necessary to keep actual and previous patch to avoid such problems. I will enhance UC admin tools to support storing of the previous patch.
I agree with proposed solution after discussion with Development and BE. In the ideal solution the AUC should keep actual and all historical patches however proposed solution will cover 99% cases.