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.
We are about to release beta of 6.5 and still, we have not adjusted the cluster names. I am not sure about the priority of the problem, but I'd call it 'blocking any progress', as having 6.5 using nb6.1 cluster seems very, very weird to me. As such I believe this issue deserves to be marked as P1. On other, architectural role, I think all clusters shall be marked as "potentially incompatible". As I am not sure anyone would really try to guarantee "bug-to-bug" compatibility for any cluster. At least, please increase the platform cluster name to platform9.
Clearly this would mean changes to cluster.properties and netbeans.clusters, as well as various Hudson scripts in nbbuild/hudson and nbbuild/newbuild. Whether there remain other files in the source base which would also need to be updated, I am not sure - IIRC Yarda did a big cleanup of gratuitous usages of cluster names a few months ago, but I don't know how complete this was, i.e. there might still be some random build script hiding in visualweb or elsewhere which hardcodes the name of a 6.1 (or even earlier!) cluster. To be safe it is necessary to do a textual search at least across all build scripts and properties files in the source base. As I have mentioned in the past to Yarda, I believe the habit of putting a number in cluster names is a very bad idea and we should stop it. Besides the usual busy work at every release updating a bunch of files in our sources, it causes problems for third-party module developers switching NB platforms. It is supposed to be a way to indicate the compatibility level of a cluster (vague as this notion is, compared to module-level compatibility), but this could be done both more easily and more clearly by putting some kind of README in the distribution (or perhaps one per cluster) explaining major known compatibility problems from the last release. (What directory layout we use for native packaging on Unix systems is a separate concern - there is nothing stopping us from using e.g. /usr/share/lib/netbeans/65/platform as a cluster directory in such an environment, or from having some hypothetical non-"NetBeans IDE" product mix and match clusters from packages released at different times. This should not be seen as a constraint on how we build the IDE, or how we distribute it to the great majority of users who are not using such a packaging system.)
Stando, do the increase for nb6.1 -> nb6.5 platform8 -> platform9 ide9 -> ide10 I'll notify other teams to consider increasing their cluster numbers as appropriate after we have done it for these clusters. Put a list of places you had to touch into wiki. We'll point others to the list. Thanks.
done: dad399bb4c64 there are too many places where cluster names had to be changed, see the revision in hg. i don't think listing them in wiki would be useful to anyone. but the good news is that a simple search & replace should the job with the following exceptions: cnd.discovery/createOpenSourceProjects.bash cnd.modelimpl/tracemodel.sh apisupport.feedreader/feedreader-suite/nbproject/platform.properties apisupport.paintapp/PaintApp-suite/nbproject/platform.properties
What a mess. I agree that simply listing files to update in wiki would be a bad idea; it would be out of date every time. bpel.project/src/org/netbeans/modules/bpel/project/resources/build-impl.xsl is just being stupid; it should be using <fileset> to match patterns. I don't supposed you checked contrib for the old cluster names too?
> I don't supposed you checked contrib for the old cluster names too? no, i didn't
Well contrib may need to be updated (after your changeset propagates to main).