It's possibly the Version number not changing attributes (can't fully outrule that either), but please ensure in future changes to data or other key dependencies won't break the build:-\
Unless of course we Finally did a proper Maven deployment of deliverables already released, not just put binary files into SVN in several places which is not usable to anybody;-) Until the Maven deficit is fixed we'll have to do any such experiments or previews on a Branch, not trunk to keep Jenkins happy. Werner Am 03.09.2014 02:08 schrieb "Reza" <[email protected]>: > I agree, I fully expect to have a rigorous vocabulary and attribute review > when it comes to 2.0. I honestly did not expect this much fuss over 2 > attributes in 1.0.*, but I welcome the discussion :) Since these attributes > only exist in the new 1.0.1 devices, I agree they should be removed and > revisited in 2.0. I will remove them shortly. > > As for release date, YYYY-mm sounds good. > > Pixel density is a *must* attribute for 2.0. With pixel density, we can > calculate the physical screen dimensions, or the other way around, screen > dimensions gives us pixel density. Its cleaner to store the density. Do we > have the physical screen dimensions for pre devicemap devices in your > database? Ex: 2.5in x 4.4in > > > ________________________________ > From: Werner Keil <[email protected]> > To: "[email protected]" < > [email protected]> > Sent: Tuesday, September 2, 2014 7:43 PM > Subject: Re: device data 1.0.1 - preview > > > Good point, we should keep a certain sanity especially regarding data, > since it affects all major clients, I recall to have mentioned that > earlier;-) > > Werner > > > > > On Wed, Sep 3, 2014 at 12:46 AM, eberhard speer jr. <[email protected]> > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, > > > > > So I added 2 new properties to the devices, release year and pixel > > > density. No real motive... > > > > The point is not the reason, not the "motive", the point is the manner. > > We all appear to agree the Vocabulary needs a review and more, better > > Properties, but let's not use "so I added..." as a method. > > So, please stop adding properties before we reach consensus on their > > need, format etc. > > > > With regard to release date, which I agree should be added, the > > YYYY-mm -- it is a standard after all -- appears to be the consensus. > > So, I have no objections to it being added in that format. > > [I can provide release dates for existing devices -- where known] > > > > I'm not sure about the pixel density. Not so much the need to include > > it, I can see that, but because of the fact that more 'similar' > > Properties may be included in the big Data 2.0 update which is > > planned. So, I'd say, if you must, include it [how many devices out of > > a total of...] keeping in mind that its name and format [why not > > include the unit of measure, for example] may change for 2.0. > > > > So : > > Release date : yes please : YYYY-mm > > Pixel density : yes...but better wait for 2.0 > > > > esjr > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.22 (MingW32) > > > > iQEcBAEBAgAGBQJUBkjKAAoJEOxywXcFLKYcZ3EH/jdNEftbHuD5B2vbiTrNaJ5m > > BSzqvudSCC0PaMA58pi4xV0zn9EcuxmdkOu2zcy915hWTCk7KE97lhiyYLptFGnG > > Rdzt6aPgLnf8wkH53daFaYCAbkLWPdeBmiOBtn9iN215LOo6d0bDbKSE4JqCxt3j > > rWsGD49jr6T+VyRXBScWkjLIA0d1zDdzyRoZTh3kc2YMrYL1+WTAzXfpc0mYCV4q > > pTSTIcHe1nbiJKvikuTZTCEiYyUGw2I0LXbl2a0KcfolbPr0amw38XJYoZEOl3G1 > > IjR8Jagr/OAiOmlqL/prxflA3ISGIfIw2QUEnNBQPWrM+dH6nlYpv63Lj78JG2M= > > =P44+ > > -----END PGP SIGNATURE----- > >
