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