Re: Last Straw... I have had it!
"Edward Mann" <[email protected]> Thu, 10 Jul 2008 15:41:21 -0500 (CDT)
| Newsgroups | gmane.comp.ide.eclipse.phpeclipse.devel |
|---|---|
| Message-ID | <14984.198.102.252.12.1215722481.squirrel@webmail.arctechnologies.net> |
> Edward Mann wrote: >>> Edward Mann wrote: >>>> Ok, >>>> >>>> So i have had it with this 3.2 fragment issue. I have tried to get it >>>> to >>>> build, but my working environment is to new and is causing more issues >>>> for me working on 3.2. I have a version in Nightly that works. My idea >>>> is to keep it, make a update site for 3.2 and say if you want support >>>> move to 3.3. I have issues with 3.4 that i would like to work on, and >>>> i >>>> want to get things cleaned up for 3.4. >>>> >>>> So if someone else wants to take the 3.2 issue and work on it i will >>>> help where i can, it's mostly working, but it needs more attention, >>>> right now it will load the compatibility patch for everyone. I tried a >>>> workaround, but that only ended up in breaking the build. So i am >>>> throwing in the towel. I don't see it worth my time to get PHPEclipse >>>> 1.2.0 working on a very old version of Eclipse. >>>> >>>> Also as it seems only two people tend to answer these posts, Mbowie, >>>> we >>>> will have an arm wrestling match and the winner get's to decide if we >>>> push 1.2.0 out with 3.3 support only. The 1.2.0 series will support >>>> Eclipse 3.3. The 1.3.0 will support 3.4, and if we can get stuff done >>>> quicker than the 1.2.0 release, we will work on making 1.4.0 work with >>>> Eclipse 3.5 and have it out close to the time they do the next major >>>> release of Eclipse. Then maybe for the 3.6 release of Eclipse we can >>>> get >>>> in on the "all plug-ins release at same time" fun. >>>> >>>> >From talking with someone (zx) in the Eclipse channel we should >>>> target a >>>> release of PHPEclipse per Eclipse release. Because some items that we >>>> depend upon in a new release of PHPEclipse may not be in an older >>>> release of Eclipse. And like i said before we are not a large team, so >>>> we cannot branch and have people support different versions. But then >>>> again if someone wants to step forward and do that i am all for it. >>>> But >>>> your not volunteering me for the job. I don't mind fixing bugs, but >>>> it's >>>> gotta be worth fixing for me. >>>> >>> Good day folks, >>> >>> I think the victory here is being overshadowed by somewhat of a minor >>> issue... the fact is that a rather annoying compatibility issue, >>> (which, >>> IMHO was partially introduced upstream,) has been resolved! Big >>> high-fives all round for Mr Mann, as he's done a great job working it >>> out amongst all his other "real world" commitments. >>> >>> I'd like to suggest that we roll a final 1.1.x build with the fragment >>> included, then push 1.2.0 without it. In an ideal world, I'd like to >>> see the project continue to support 3.2, but I do agree that moving >>> forward is a more pressing need. I'd imagine that the nightly is going >>> to go through some pretty radical "changes" in the few months following >>> 1.2.0, so hopefully we'll see the majority of users using the stable >>> build. >>> >>> I would like to keep the 3.2 fragment and any notes related to it handy >>> though... while I appreciate what people are saying about 3.2 being >>> old, >>> from what we see in IRC, it is a widely used build; and there are users >>> who are quite happy with 3.2. I personally think it's a case of the >>> "tail wagging to dog" for a plugin to force you to update your >>> environment... that sounds like something a business driven model would >>> do. I also understand the point that the Eclipse project deems 3.2 to >>> be "old news", but if PHPEclipse's visions were parallel to that of the >>> Eclipse Foundation, we'd all have joined the PDT project long ago. >>> >>> So let's not overlook the fact that we have a solution which we can >>> "roll by hand" for the time being; and if we continue to see this as an >>> issue as we approach future milestones, maybe it can be re-addressed >>> then. I'd be happy to pickup Mr Mann's efforts at some point, should >>> the need arise. >>> >>> Perhaps we could consider adding an "opt-in" anonymous usage statistics >>> feature... something which reported a handful of platform and version >>> number details on startup. In future, that would give us *some* idea >>> of >>> the builds in the wild and the platforms actively in use. Although, I >>> think said feature would be even better in the Eclipse core. >>> >>> I think this is awesome progress... great work Mr Mann! >>> >>> Mike. >>> >> >> Mike, >> >> If i am reading you correct, this is what i am going to do. >> >> I am going to make a 1.1.9 release of PHPEclipse that has the fragment >> installed. Users with Eclipse 3.2 will need to use this release. >> >> Then i am going to make another release for Eclipse 3.3 for 1.2.0. This >> will be a build right from trunk without the fragment. And users of >> Eclipse 3.3 will use this build. >> >> We would only be doing fixes in trunk, and testing on 3.3 of Eclipse. >> The >> Hudson build for 1.2.0 will move to the Eclipse 3.3 SDK. I have been >> building with 3.2... i believe. >> >> Anything missing? >> >> Thanks for the responses everyone. Now i don't feel like the lone voice >> shouting into the darkens. >> > > Edwardo, > > That is indeed what I'm suggesting. > > Mike. > Mike, I will make it so number 1. I will get this done 2night. I will get release update sites up and going. I will see if i can get this done tonight. Thanks. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08