Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Can we drop 32bit EPP Packages?

I cannot explain the high number of 32-bit downloads, but given that a user needs to *actively* decide between the 32 and the 64 bit version (on the download page and with the installer), I tend to think that there must be some intention by the users (most of them are developers, right?). If someone downloads a 32-bit package, there needs to be a 32-bit JVM installed on the computer in order to run Eclipse... that doesn't come for free and needs some work of the user, too.

I have to admit that I have my doubts that a user's decision towards 32-bit is a good one, or a required one, in all those cases, but that is what the statistics tells us. Maybe there is better statistical data from the error reporter?

Regards,
Markus


On 17 February 2016 at 10:26, Arthur van Dorp <Arthur.vanDorp@xxxxxxxxxxxxxxxx> wrote:

I wonder how many of those 32 bit downloads are deliberate or just out of habit and/or not knowing what to download. Do we have numbers from problem reports or some such which would give some impression of real world usage?

 

Regards,

Arthur

 

Von: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] Im Auftrag von Markus Knauer
Gesendet: Mittwoch, 17. Februar 2016 09:58
An: Eclipse Packaging Project
Betreff: Re: [epp-dev] Can we drop 32bit EPP Packages?

 

Hi Patrick,

good question... I thought about the same idea some months but even when I check the download numbers today, there are in my opinion too many downloads of the 32-bit version. Running a (very simplified) query today which includes data from the last 12 months just for the Mars release (2015-02-17 to 2016-02-17), I see a total number of about 14 million downloads and only about 10 million downloads were 64-bit downloads. Subtracting this leaves 4 million downloads for 32-bit packages which is a very high number. For the time being I would continue to build the 32-bit versions.

The configuration itself is defined in the parent pom in the Tycho target platform configuration, and is the same for all packages.

Regarding the follow up question: Yes, the 64-bit packages should probably be the default if no one comes up with good reasons why we shouldn't do so. Maybe this helps changing the statistics over time towards 64-bit, who knows.

Regards,

Markus



 

On 17 February 2016 at 09:37, Patrick Bänziger <Patrick.Baenziger@xxxxxxxxxxxxxxxx> wrote:

Hello all,

 

We in the Scout project recently debated whether we should continue supporting (read: build and test) for 32bit architectures.

As far as we can see, all EPP Packages also have a 32bit version built (except for Mac OS X) and we did not yet find an option to configure otherwise.

 

Our reasoning is that with all the OS and Java versions we do test, the test matrix is getting very large and hard to cover. And second, of all customers and other users we know, none of them has a 32bit system.

 

We do not know if it is required to build or support the 32bit architectures  (the SimRel Requirements [1] are not clear on that) and would like to ask for your input.

 

·         Is it allowed for a project to only provide 64bit packages?

·         Can we configure this?

 

And maybe a follow-up question:

·         Should maybe the 64bit packages be the default on the download page – and the 32bit only if the user explicitly selects it?
(Ubuntu, for example, shows the architecture in a drop down box with 64bit being the default, labeled “recommended”)

 

 

Regards,

Patrick

 


_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev




_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev



Back to the top