|
From: Rod J. <rod...@in...> - 2004-02-22 20:12:40
|
I agree. I'm inclined to leave it as is for now. ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Sunday, February 22, 2004 7:58 PM Subject: Re: [Springframework-developer] DTD versioning We need a final decision here: Keep "spring-beans.dtd" for the time being= , switch to "spring-beans-1.0.dtd", or switch to "spring-beans_1_0.dtd". In any case, our BeansDtdResolver is still able to resolve "spring-beans.dtd= " for backward compatibility. As I outlined earlier, DTD compatibility doesn't seem to be a major issue for users. Hibernate has a version number, but just for the major release 2.0: The modified DTD for Hibernate 2.1 still use the same file name, despite the "jcs-cache"/"cache" change. Ant doesn't even have a proper DT= D. As a counterexample, Struts uses strict DTD versioning. However, even Til= es used "tiles-config.dtd" initially, switching to "tiles-config_1_1.dtd" la= ter on. I've thought about this issue for quite a while now, and I'm inclined to leave it as "spring-beans.dtd" for the time being. We can always change t= o a versioned DTD if we feel the need to. Any final thoughts on this? Juergen ________________________________ Von: spr...@li... im Auftrag von Colin Sampaleanu Gesendet: Mi 18.02.2004 13:39 An: spr...@li... Betreff: Re: [Springframework-developer] DTD versioning Personally I'd rather get a version number in there from the get-go, especially given that we've already had a few variants. I also have no problem with the possibility that some future release (e.g. 1.2) ships with a DTD which has an unchanged version number (e.g. 1.0). I consider it a DTD version, whos primary goal is to indicate a change from one DTD to another. Of course if something does change in the DTD so you change the DTD number for another version of the DTD, it makes sense to make the new version the same as the Spring version which introduces the chang= e. But the only thing I feel pretty strongly about is chaning the version in the name when something actually changes, so if other people just want to leave the name as-is for now, I have no real objections... j=FCrgen h=F6ller [werk3AT] wrote: >I actually prefer the Hibernate style "spring-beans-1.0.dtd", as it seem= s more natural to me. After all, underscores look like a workaround for filesystems that can't handle dots in filenames. > >An interesting point is that it could well be that our bean definition format won't change for the next couple of Spring releases. All the new features that we plan to introduce are achievable with the current generi= c format. So if we recommend a versioned DTD, we have to assume that the "spring-beans-1.0.dtd" reference will be in use for Spring 1.1/1.2/etc to= o, arguably looking a bit odd. > >Hibernate is also a bit weird in that respect: "hibernate-mapping-2.0.dt= d" was modified for 2.1 but still kept the 2.0 DTD version number... Noone complained, so I guess most people are fine with DTDs that aren't version= ed (respectively not versioned in a fine-grained version). > >So a further option for us would be to stay with "spring-beans.dtd" for = as long as there aren't any significant changes in the DTD. Of course, we wo= uld allow "spring-beans.dtd" as shortcut anyway, always defaulting to the mos= t current DTD. The question is rather: What DTD name to we *recommend* to use - explicit version or not? Consequently, what DTD name will our sampl= e apps use? > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Tuesday, February 17, 2004 2:12 PM >To: spr...@li... >Subject: Re: Re [Springframework-developer] DTD versioning > > >I am ok with either one. I picked the variant I did before because it is >what Sun uses, but if somebody likes the Hibernate-style better I am ok >with that. > >j=FCrgen h=F6ller [werk3AT] wrote: > > > >>Any opinions on the exact naming of the DTD file? I'd like to commit th= e change promptly :-) >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag v= on j=FCrgen h=F6ller [werk3AT] >>Gesendet: Mo 16.02.2004 08:40 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] DTD versioning >> >> >> >>Colin, Rod, >> >>I've just adapted BeansDtdResolver to fall back to the default DTD file "spring-beans_1_0.dtd" if "spring-beans.dtd" was specified, issuing a corresponding message at INFO level (not committed yet). I guess INFO is appropriate, as "spring-beans" can simply be considered a shortcut for "spring-beans_1_0" for the time being. >> >>If we agree on the exact naming that Colin proposed, I'll commit this a= nd adapt all our bean definition declarations in the samples etc. The only alternative that I see is "spring-beans-1.0.dtd" as used by Hibernate's DTDs, while "_1_0" is the style used by Sun's DTDs. >> >>IMO, "spring-beans.dtd" should also stay available from the website, simply adding the versioned DTD file there. >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag v= on Rod Johnson >>Gesendet: So 15.02.2004 17:18 >>An: spr...@li... >>Betreff: Re: [Springframework-developer] DTD versioning >> >> >> >>Colin >> >>I agree about versioning, so long as we can avoid breaking people's >>definitions. We could have only the new URL on the web site and modify = the >>entity resolver so that it produces a log warning on finding the old on= e >>(but still resolved it). This should provide a deprecation-style upgrad= e >>path. >> >>Regards, >>Rod >> >>----- Original Message ----- >>From: "Colin Sampaleanu" <col...@ex...> >>To: <spr...@li...> >>Sent: Sunday, February 15, 2004 3:26 PM >>Subject: [Springframework-developer] DTD versioning >> >> >> >> >> >> >>>I updated the DTD on the website, and this reminds me that we should >>>version the document. I propose naming it something like >>> >>>spring-beans_1_0.dtd >>> >>>with the doctype definition being: >>> >>><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 1.0//EN" >>> "http://www.springframework.org/dtd/spring-beans_1_0.dtd"> >>> >>>If everyone is in agreement, the only question is if we should keep th= e >>>old one around (ie keep both versions) for the 1.0 release. I would >>>favour having only the new version, to avoid future confusion, althoug= h >>>this would force everybody to update their definition documents. >>> >>>Regards, >>>Colin >>> >>> >>> ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |