Did you really have such requests (which Tracker No?) or is this the revenge of the development team for the whole JRE issue ???
We observed the following additional changes that cause us severe inconvenience:
- IDEA_JAVA_HOME is not honoured any more - self extracting archive instead of zip
Why is it necessry to cause such inconvenience for the developers? Until version 655 (which was unfortunately buggy) the migration to new idea versions was as easy as unzipping the new download to a new directory (in the past, also the directory structure inside the zip file was very consistent), which made it easy to follow the latest versions. Also a fallback was very easy, because one could just leave the old zip file until the new version was proved to be usable.
Now, each time a new version comes up, the deployment is different, the bundling is different etc. etc. notably without a recognizable benefit for us. Is this really necessary, or do you just want to get rid of the testing community ???
I don't complain about changes in general, but changes that may cause inconvenience for the whole community should be introduced with care and not without SIGNIFICANT benefit for the WHOLE community. AND existing functionality should not be broken in new versions.
Best regards, Remigius (slightly annoyed and disappointed by the recent decline in quality of the hitherto really very very very very genious product!)
Yes, there were requests to make jikes location configurable. I should add to Mike's sarcastic post that if to follow the download instructions deployment and upgrade became very easy. This is the main benefit to the EAP community. Since jre is required under idea-home directory IDEA_JAVA_HOME is not needed. Just unpack the JRE to IDEA installation directory. Why is this inconvenient? What are the problems with the self-extracting archive? We are trying to reduce the download size of our archives, thus we started to use the rar archiver instead of zip. It produces archive of smaller size. Since rar is not so wide-spread as zip, we decided to make the archive self-extracting. Is this really unconvenient for the users? I doubt. The deployment is different, you are right, but didn't it become easier?
--
Best regards, Eugene Zhuravlev JetBrains, Inc, http://www.intellij.com "Develop with pleasure!"
Did you really have such requests (which Tracker No?) or is this the
revenge of the development team for the whole JRE issue ??? >
We observed the following additional changes that cause us severe
inconvenience: >
- IDEA_JAVA_HOME is not honoured any more - self extracting archive instead of zip
>
Why is it necessry to cause such inconvenience for the developers? Until
version 655 (which was unfortunately buggy) the migration to new idea versions was as easy as unzipping the new download to a new directory (in the past, also the directory structure inside the zip file was very consistent), which made it easy to follow the latest versions. Also a fallback was very easy, because one could just leave the old zip file until the new version was proved to be usable. >
Now, each time a new version comes up, the deployment is different, the
bundling is different etc. etc. notably without a recognizable benefit for us. Is this really necessary, or do you just want to get rid of the testing community ??? >
I don't complain about changes in general, but changes that may cause
inconvenience for the whole community should be introduced with care and not without SIGNIFICANT benefit for the WHOLE community. AND existing functionality should not be broken in new versions. >
Best regards, Remigius (slightly annoyed and disappointed by the recent
decline in quality of the hitherto really very very very very genious product!) >
Well, if you experience any problems (including crashes etc) with latest IDEA builds you might submit them into out bug tracking system. I didn't find ANY request submitted by you though. :(
Indeed, the tracker issues from my company have been posted by my collegue, Claus Helbing. Several of them have been implemented. You are welcome to have a look at them. I have posted a few before Tracker was set up. Someone may find them in his e-mail archive. I'm not going to repost them for completeness :-p
Well, I'm talking about requests concerning the crashes & internal assertions (or other critical bugs) found by you in the LATEST builds (otherwise why did you stay with #651?). They are defenitely not the ones posted by you before setting up the Tracker, so I guess they are issues posted your collegue.
I found 8 requests submitted by him: - 3 of them are fixed - 1 is a feature (open to be implemented in future) - 3 are closed with "Do not fix" resolution by different reasons but none of them are crashes or assertions - 1 is a duplicate of another request which is not repeatable at the moment. This issue is from 31 August though.
Indeed, the tracker issues from my company have been posted by my
collegue, Claus Helbing. Several of them have been implemented. You are welcome to have a look at them. I have posted a few before Tracker was set up. Someone may find them in his e-mail archive. I'm not going to repost them for completeness :-p
Yes, there were requests to make jikes location configurable.
Exactly, this was request #5677 - notably for build 660. ees thees some kind of precog?
OK, now to the inconveniences:
- mainly the destabilisation of the upgrade procedure is inconvenient. Having to find out each time how to install, because it's different each time, is IMHO not necessary. - the JRE issue was - as far as I understood - not ONLY about download size (although I have the impression the IDEA team wants to tnink so). There's a big difference between 10% and 150% (sorry, the actual figures may differ). - No, the deployment did (for me!) definitely NOT become easier. Since the introduction of IDEA_JAVA_HOME it was (for me) as easy as can be (which is why I keep posting): unpack a zip file to a new directory (I pick the last unpack path from WinZip's MRU list and change the last digit, sometimes the last two), change the path of the shortcut, DONE! The rollback is even easier: just change the path in the shortcut, finito! - Since: A self extractor has no MRU list. The packaging varies each time. It is not clear how to integrate the JRE (my collegue has tried - I haven't - we have both other things to do).
As idea is NEARLY perfect (honestly!), it's becoming more and more difficult to improve. The risk grows that changes are not for the better, but for the worse. I think that the EAP community is refraining from a fast follow-up of new builds if updating is not as easy as can be. Why not just leave the packaging it as it was until 655 (or at least provide a 'classic' package for us renegades)?
If you seek new challenges, I might suggest the following:
- a GUI editor (this may violate your philosophy, but currently I wrestle with NetBeans only for GUI editing) - better support for ant's build properties in external property files (syntay highlighting) - better support for tag libraries in JSPs (I know that this correct JSP highlighting is a major issue). - metrics - more code inspections
OK, Mike's response was rather sarcastic, so mine was, too.
Seriously: I have not discovered any serious bugs in 655 and later, because 655 was unusable for us due to the XML (or and script) editing bug and later versions were not easily deployable (IMHO). I have not had the time to experiment with post-655 builds, and my collegue Claus had bad experiences (he could not install 660 before he grew too impatient to resist downgrading to 651).
As soon as there's a version the first of us deems worthy following, we start using it and report bugs if we find some. As we are humans (hey hey!) we can not define sharp criteria when this will be the case - but a healthy version (= being able to work with no more than about two nasty errors per day) with a pre-658 packaging will most likely do. However, if there are bugs like the error message at the file ends or the unability to edit ant scripts, or inconveniences like the packaging changes, we reserve our right to find the new version bad without further justification, but just because we don't like it. Then we don't use it, and because we don't use it, we won't report any bugs.
The reason why I write all this is because I think it may have an impact. I still think IDEA is the very best development environment and it is a real asset for the whole developer community. Every time I have to use an other IDE (like NetBeans or Visual Studio), I get homesick! In our discussions, my collegue and I came to the conclusion that the quality of IDEA is about to decline. This worries me, and I'd like to help you to get on track again. The best way that I can find is by expressing my thoughts, instead of going home early.
It is not clear how to integrate the JRE (my collegue has tried - I haven't - we have both other things to do).
We thought that installation instructions on download pages are quite clear: to unpack the jre zip file into the IDEA folder.
- No, the deployment did (for me!) definitely NOT become easier.
I'm hitting Enter on ".exe" file in WinCmd, point it to my IDEA location & press OK. The end of upgrade procedure. Is it too difficult? If so, we'll begin to think on providing only installers in future.
>However, if there are bugs like the error message at the file ends or the unability to edit ant scripts, or inconveniences like the packaging changes, we
reserve our right to find the new version bad without further
justification, but just because we don't like it. Then we don't use it, and because we don't use
it, we won't report any bugs.
Well, if there are such critical bugs then you don't use it and don't report MORE bugs. But these ones should be reported into the Tracker! Otherwise how would we know about your problems??
The reason why I write all this is because I think it may have an impact.
I still think IDEA is the very best development environment and it is a real asset
for the whole developer community. Every time I have to use an other IDE
(like NetBeans or Visual Studio), I get homesick! In our discussions, my
collegue and I came to the conclusion that the quality of IDEA is about to
decline. This worries me, and I'd like to help you to get on track again. The best
way that I can find is by expressing my thoughts, instead of going home
early.
Thank you for your kind words. We hope the quality of IDEA will not decline and we hope YOU will help us with that. The best way of doing it is submitting issues into the tracker instead of expressing your emotions!
OK, Mike's response was rather sarcastic, so mine was, too.
>
Seriously: I have not discovered any serious bugs in 655 and later,
because 655 was unusable for us due to the XML (or and script) editing bug and later versions were not easily deployable (IMHO). I have not had the time to experiment with post-655 builds, and my collegue Claus had bad experiences (he could not install 660 before he grew too impatient to resist downgrading to 651). >
As soon as there's a version the first of us deems worthy following, we
start using it and report bugs if we find some. As we are humans (hey hey!) we can not define sharp criteria when this will be the case - but a healthy version (= being able to work with no more than about two nasty errors per day) with a pre-658 packaging will most likely do. However, if there are bugs like the error message at the file ends or the unability to edit ant scripts, or inconveniences like the packaging changes, we reserve our right to find the new version bad without further justification, but just because we don't like it. Then we don't use it, and because we don't use it, we won't report any bugs. >
The reason why I write all this is because I think it may have an impact.
I still think IDEA is the very best development environment and it is a real asset for the whole developer community. Every time I have to use an other IDE (like NetBeans or Visual Studio), I get homesick! In our discussions, my collegue and I came to the conclusion that the quality of IDEA is about to decline. This worries me, and I'd like to help you to get on track again. The best way that I can find is by expressing my thoughts, instead of going home early. >
Sorry, I don't think this discussion is very enlightening. For me this is serious concern, as it affects my dayly work - for you as it effects your work's results and probably your self esteem. I think you don't want to listen to what I'm telling.
As my collegue is already home with his family, I can'0t blame him for not reading the download page. But I can tell that reading the download page is already additional effort (see my previous description of the upgrade procedure). Furthermore, you don't explain how to downgrade. Downgrade is still an important issue, as it occurs frequently (and I don't blame anyone for that) that a new build is judged not usable for our purposes for one reason or another. However, it has not occurred yet so far that THREE subsequent builds were judged unusable by us. Sorry for that, but we must admit it's only our fault, an RTFM phenomenon coupled with our attitude, cultural aberration and wrong shoe color, most likely.
We check tracker. If we find the bug (which is the case with most serious bugs and other issues, like the two that I mentioned) we don't report them again, but wait 'til a new version comes out in which the bug is fixed. No, we don't use it because, remember, the bug is critical for us which means we can't use it to achieve our goals. In other cases, like this here, I take part in the discussion, hoping (maybe erroneously) this has some impact.
As I have stated in a previous post, I am human therefore I HAVE emotions ant I refuse to throw them out of the window. Furthermore, although you may not agree to this, I think you deserve getting to know the (positive and negative) emotions of the user community, as these are most valuable to you. Use them!
I can't blame him for not reading the download page.
Man, I thought I had it bad. Do you realize how absurd you sound? ;)
1) Load page 2) Hit Download 3) Sit while files Download...
During step 3 is trivial to read the page. Your attitude seems to be that nothing should be changed at all lest stupid users have their time wasted when they fail to follow directions.
If the directions were hard to get to, complicated, or burdensome above and beyond what is generally expected -- then you might have a point. As it is you're effectively wasting the time of people who could otherwise be improving a product you obviously find valuable.
You know, you could go back and use 2.6 if this is costing you so much time with its burdensome install sarcasm alert.
Personally I like the new installation. I just dump the jre into the directory I dumped the sfx into. Even if you unzip you still have to point it to the directory to unzip.
Basically,
1) So what if some of the builds were unusable for you. It's an EAP, it's not finished code. Use the one that works best for you if you aren't going to keep using 2.6. Yes, you may realize that but it sounds like you don't with some of your comments.
2) Read the notes while you download the latest build. If you've got the time to reconfigure IDEA for each build you download then you have time to read the install notes. I still don't see how its more difficult...I mean you don't even have to edit the idea.bat file anymore if your JDK install is in a different directory other than the default!
3) Its an EAP...things will change, the install will change...heck, even the config file formats change. I understand that as a developer my code goes through constant refactoring and I'm not going to spend ANY time making sure that its backwards compatible or upgradable for early access users as I make new builds available. Sorry, just the price you pay.
Guys, I like the new install process....hopefully my vote cancels out his vote.
Different users want different jikes versions.
Exactly Carlos!
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Carlos Costa e Silva" <carlos@keysoft.pt> wrote in message
news:aogcjp$3fi$1@is.intellij.net...
>
>
>
Did you really have such requests (which Tracker No?) or is this the revenge of the development team for the whole JRE issue ???
We observed the following additional changes that cause us severe inconvenience:
- IDEA_JAVA_HOME is not honoured any more
- self extracting archive instead of zip
Why is it necessry to cause such inconvenience for the developers? Until version 655 (which was unfortunately buggy) the migration to new idea versions was as easy as unzipping the new download to a new directory (in the past, also the directory structure inside the zip file was very consistent), which made it easy to follow the latest versions. Also a fallback was very easy, because one could just leave the old zip file until the new version was proved to be usable.
Now, each time a new version comes up, the deployment is different, the bundling is different etc. etc. notably without a recognizable benefit for us. Is this really necessary, or do you just want to get rid of the testing community ???
I don't complain about changes in general, but changes that may cause inconvenience for the whole community should be introduced with care and not without SIGNIFICANT benefit for the WHOLE community. AND existing functionality should not be broken in new versions.
Best regards, Remigius (slightly annoyed and disappointed by the recent decline in quality of the hitherto really very very very very genious product!)
Aha. We are also planning to introduce several crashes & internal assertions
as the part of revenge.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
I have already noticed some of them. Sticking with 651.
Hi Remigius,
Yes, there were requests to make jikes location configurable.
I should add to Mike's sarcastic post that if to follow the download
instructions deployment and upgrade became very easy. This is the main
benefit to the EAP community.
Since jre is required under idea-home directory IDEA_JAVA_HOME is not
needed. Just unpack the JRE to IDEA installation directory. Why is this
inconvenient?
What are the problems with the self-extracting archive? We are trying to
reduce the download size of our archives, thus we started to use the rar
archiver instead of zip. It produces archive of smaller size. Since rar is
not so wide-spread as zip, we decided to make the archive self-extracting.
Is this really unconvenient for the users? I doubt.
The deployment is different, you are right, but didn't it become easier?
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Remigius Stalder" <remigius.stalder@descom-consulting.ch> wrote in message
news:1166005.1034700051652.JavaMail.javamailuser@localhost...
revenge of the development team for the whole JRE issue ???
>
inconvenience:
>
>
version 655 (which was unfortunately buggy) the migration to new idea
versions was as easy as unzipping the new download to a new directory (in
the past, also the directory structure inside the zip file was very
consistent), which made it easy to follow the latest versions. Also a
fallback was very easy, because one could just leave the old zip file until
the new version was proved to be usable.
>
bundling is different etc. etc. notably without a recognizable benefit for
us. Is this really necessary, or do you just want to get rid of the testing
community ???
>
inconvenience for the whole community should be introduced with care and not
without SIGNIFICANT benefit for the WHOLE community. AND existing
functionality should not be broken in new versions.
>
decline in quality of the hitherto really very very very very genious
product!)
>
Well, if you experience any problems (including crashes etc) with latest
IDEA builds you might submit them into out bug tracking system. I didn't
find ANY request submitted by you though. :(
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Remigius Stalder" <remigius.stalder@descom-consulting.ch> wrote in message
news:2165498.1034700845033.JavaMail.javamailuser@localhost...
Indeed, the tracker issues from my company have been posted by my collegue, Claus Helbing. Several of them have been implemented. You are welcome to have a look at them. I have posted a few before Tracker was set up. Someone may find them in his e-mail archive. I'm not going to repost them for completeness :-p
Well, I'm talking about requests concerning the crashes & internal
assertions (or other critical bugs) found by you in the LATEST builds
(otherwise why did you stay with #651?). They are defenitely not the ones
posted by you before setting up the Tracker, so I guess they are issues
posted your collegue.
I found 8 requests submitted by him:
- 3 of them are fixed
- 1 is a feature (open to be implemented in future)
- 3 are closed with "Do not fix" resolution by different reasons but none
of them are crashes or assertions
- 1 is a duplicate of another request which is not repeatable at the
moment. This issue is from 31 August though.
What are the crashes you was talking about?
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Remigius Stalder" <remigius.stalder@descom-consulting.ch> wrote in message
news:5457859.1034701653645.JavaMail.javamailuser@localhost...
collegue, Claus Helbing. Several of them have been implemented. You are
welcome to have a look at them. I have posted a few before Tracker was set
up. Someone may find them in his e-mail archive. I'm not going to repost
them for completeness :-p
Exactly, this was request #5677 - notably for build 660. ees thees some kind of precog?
OK, now to the inconveniences:
- mainly the destabilisation of the upgrade procedure is inconvenient. Having to find out each time how to install, because it's different each time, is IMHO not necessary.
- the JRE issue was - as far as I understood - not ONLY about download size (although I have the impression the IDEA team wants to tnink so). There's a big difference between 10% and 150% (sorry, the actual figures may differ).
- No, the deployment did (for me!) definitely NOT become easier. Since the introduction of IDEA_JAVA_HOME it was (for me) as easy as can be (which is why I keep posting): unpack a zip file to a new directory (I pick the last unpack path from WinZip's MRU list and change the last digit, sometimes the last two), change the path of the shortcut, DONE! The rollback is even easier: just change the path in the shortcut, finito!
- Since: A self extractor has no MRU list. The packaging varies each time. It is not clear how to integrate the JRE (my collegue has tried - I haven't - we have both other things to do).
As idea is NEARLY perfect (honestly!), it's becoming more and more difficult to improve. The risk grows that changes are not for the better, but for the worse. I think that the EAP community is refraining from a fast follow-up of new builds if updating is not as easy as can be. Why not just leave the packaging it as it was until 655 (or at least provide a 'classic' package for us renegades)?
If you seek new challenges, I might suggest the following:
- a GUI editor (this may violate your philosophy, but currently I wrestle with NetBeans only for GUI editing)
- better support for ant's build properties in external property files (syntay highlighting)
- better support for tag libraries in JSPs (I know that this correct JSP highlighting is a major issue).
- metrics
- more code inspections
(I'm sure other developers have some more ideas).
Best regards, Remigius.
OK, Mike's response was rather sarcastic, so mine was, too.
Seriously: I have not discovered any serious bugs in 655 and later, because 655 was unusable for us due to the XML (or and script) editing bug and later versions were not easily deployable (IMHO). I have not had the time to experiment with post-655 builds, and my collegue Claus had bad experiences (he could not install 660 before he grew too impatient to resist downgrading to 651).
As soon as there's a version the first of us deems worthy following, we start using it and report bugs if we find some. As we are humans (hey hey!) we can not define sharp criteria when this will be the case - but a healthy version (= being able to work with no more than about two nasty errors per day) with a pre-658 packaging will most likely do. However, if there are bugs like the error message at the file ends or the unability to edit ant scripts, or inconveniences like the packaging changes, we reserve our right to find the new version bad without further justification, but just because we don't like it. Then we don't use it, and because we don't use it, we won't report any bugs.
The reason why I write all this is because I think it may have an impact. I still think IDEA is the very best development environment and it is a real asset for the whole developer community. Every time I have to use an other IDE (like NetBeans or Visual Studio), I get homesick! In our discussions, my collegue and I came to the conclusion that the quality of IDEA is about to decline. This worries me, and I'd like to help you to get on track again. The best way that I can find is by expressing my thoughts, instead of going home early.
Best regards, Remigius.
Forgot:
- integration of UML editing
(may be out of scope as well, but would be very handy)
We thought that installation instructions on download pages are quite clear:
to unpack the jre zip file into the IDEA folder.
I'm hitting Enter on ".exe" file in WinCmd, point it to my IDEA location &
press OK. The end of upgrade procedure. Is it too difficult? If so, we'll
begin to think on providing only installers in future.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
>However, if there are bugs like the error message at the file ends or the
unability to edit ant scripts, or inconveniences like the packaging changes,
we
justification, but just because we don't like it. Then we don't use it, and
because we don't use
Well, if there are such critical bugs then you don't use it and don't report
MORE bugs. But these ones should be reported into the Tracker! Otherwise how
would we know about your problems??
I still think IDEA is the very best development environment and it is a real
asset
(like NetBeans or Visual Studio), I get homesick! In our discussions, my
decline. This worries me, and I'd like to help you to get on track again.
The best
early.
Thank you for your kind words. We hope the quality of IDEA will not decline
and we hope YOU will help us with that. The best way of doing it is
submitting issues into the tracker instead of expressing your emotions!
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Remigius Stalder" <remigius.stalder@descom-consulting.ch> wrote in message
news:5238287.1034704213898.JavaMail.javamailuser@localhost...
>
because 655 was unusable for us due to the XML (or and script) editing bug
and later versions were not easily deployable (IMHO). I have not had the
time to experiment with post-655 builds, and my collegue Claus had bad
experiences (he could not install 660 before he grew too impatient to resist
downgrading to 651).
>
start using it and report bugs if we find some. As we are humans (hey hey!)
we can not define sharp criteria when this will be the case - but a healthy
version (= being able to work with no more than about two nasty errors per
day) with a pre-658 packaging will most likely do. However, if there are
bugs like the error message at the file ends or the unability to edit ant
scripts, or inconveniences like the packaging changes, we reserve our right
to find the new version bad without further justification, but just because
we don't like it. Then we don't use it, and because we don't use it, we
won't report any bugs.
>
I still think IDEA is the very best development environment and it is a real
asset for the whole developer community. Every time I have to use an other
IDE (like NetBeans or Visual Studio), I get homesick! In our discussions, my
collegue and I came to the conclusion that the quality of IDEA is about to
decline. This worries me, and I'd like to help you to get on track again.
The best way that I can find is by expressing my thoughts, instead of going
home early.
>
Sorry, I don't think this discussion is very enlightening. For me this is serious concern, as it affects my dayly work - for you as it effects your work's results and probably your self esteem. I think you don't want to listen to what I'm telling.
As my collegue is already home with his family, I can'0t blame him for not reading the download page. But I can tell that reading the download page is already additional effort (see my previous description of the upgrade procedure). Furthermore, you don't explain how to downgrade. Downgrade is still an important issue, as it occurs frequently (and I don't blame anyone for that) that a new build is judged not usable for our purposes for one reason or another. However, it has not occurred yet so far that THREE subsequent builds were judged unusable by us. Sorry for that, but we must admit it's only our fault, an RTFM phenomenon coupled with our attitude, cultural aberration and wrong shoe color, most likely.
OK, what do we do when we discover these bugs?
We check tracker. If we find the bug (which is the case with most serious bugs and other issues, like the two that I mentioned) we don't report them again, but wait 'til a new version comes out in which the bug is fixed. No, we don't use it because, remember, the bug is critical for us which means we can't use it to achieve our goals. In other cases, like this here, I take part in the discussion, hoping (maybe erroneously) this has some impact.
As I have stated in a previous post, I am human therefore I HAVE emotions ant I refuse to throw them out of the window. Furthermore, although you may not agree to this, I think you deserve getting to know the (positive and negative) emotions of the user community, as these are most valuable to you. Use them!
Remigius Stalder wrote:
Man, I thought I had it bad. Do you realize how absurd you sound? ;)
1) Load page
2) Hit Download
3) Sit while files Download...
During step 3 is trivial to read the page. Your attitude seems to be
that nothing should be changed at all lest stupid users have their time
wasted when they fail to follow directions.
If the directions were hard to get to, complicated, or burdensome above
and beyond what is generally expected -- then you might have a point. As
it is you're effectively wasting the time of people who could otherwise
be improving a product you obviously find valuable.
James
You know, you could go back and use 2.6 if this is costing you so much time with its burdensome install sarcasm alert.
Personally I like the new installation. I just dump the jre into the directory I dumped the sfx into. Even if you unzip you still have to point it to the directory to unzip.
Basically,
1) So what if some of the builds were unusable for you. It's an EAP, it's not finished code. Use the one that works best for you if you aren't going to keep using 2.6. Yes, you may realize that but it sounds like you don't with some of your comments.
2) Read the notes while you download the latest build. If you've got the time to reconfigure IDEA for each build you download then you have time to read the install notes. I still don't see how its more difficult...I mean you don't even have to edit the idea.bat file anymore if your JDK install is in a different directory other than the default!
3) Its an EAP...things will change, the install will change...heck, even the config file formats change. I understand that as a developer my code goes through constant refactoring and I'm not going to spend ANY time making sure that its backwards compatible or upgradable for early access users as I make new builds available. Sorry, just the price you pay.
Guys, I like the new install process....hopefully my vote cancels out his vote.
Keep up the great work!!!
-Mike