I also vote for folder-level versioning, it makes for a one spot
change to update versions manually. As for plugins, I don't suspect
that the authors will be as strict with version numbering as the core
should be. My pattern is like this though:
(if(Breaks API)++).(if(Adds minor features and doesn't break API)++).
(if(Fixes bugs)++)
On Oct 6, 8:42 am, "Jörn Zaefferer" <[EMAIL PROTECTED]>
wrote:
> Looking at tags in subversion, 1.x is used for major releases, 1.x.x
> for minor, and in contrast to what I was worrying about, the order
> doesn't get messed up. So we can just stick with that.
>
> I'll try to modify the plugins/build.xml ant script to put the version
> into the folder it creates inside the zip file. Otherwise we need some
> refactoring, moving css and image files to theme and theme/images.
>
> Jörn
>
> On Mon, Oct 6, 2008 at 1:22 PM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Oct 5, 2008 at 11:37 PM, Jörn Zaefferer
> > <[EMAIL PROTECTED]> wrote:
>
> >> About versioning: Should be always use full numbers? That is, 1.0.0
> >> instead of 1.0? It certainly has advantages when listing various
> >> versions.
>
> > Sounds like a good idea but I'm not sure what the convention is currently
> > with jQuery and UI. Might be best to follow existing convention?
>
> >> Should file names have versions? The base folder? So far I'd prefer to
> >> have the version in the base folder that contains everything else, and
> >> within the actual plugin files, but not in the plugin file names.
>
> > I agree. We should not add version numbers to file names.
>
> >> Jörn
>
> >> On Sun, Oct 5, 2008 at 5:23 PM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote:
> >> > Exactly. Even on the rare occasion when someone uses a full url with
> >> > http://
> >> > it is pretty simple to just ignore those.
>
> >> > On Sun, Oct 5, 2008 at 10:57 PM, Jörn Zaefferer
> >> > <[EMAIL PROTECTED]> wrote:
>
> >> >> That would simply assume that any URL within the CSS file is a
> >> >> relative URL, which seems to be a safe bet. Having absolute URLs in
> >> >> there doesn't make too much sense anyway, at least not in this
> >> >> context.
>
> >> >> Jörn
>
> >> >> On Sun, Oct 5, 2008 at 7:11 AM, Ca-Phun Ung <[EMAIL PROTECTED]>
> >> >> wrote:
> >> >> > Good stuff! One post from Jörn is better than a thousand from me,
> >> >> > hehe
> >> >> > :)
> >> >> > I'd say however that even the /* [relative-url] */ marker is not
> >> >> > necessary
> >> >> > and just another chance for error. What you could do simply is find
> >> >> > all
> >> >> > url(....) references and extract the necessary URL details within.
> >> >> > It's
> >> >> > probably not as simple as that but you get the gist. :)
>
> >> >> > On Sun, Oct 5, 2008 at 2:52 AM, Yehuda Katz <[EMAIL PROTECTED]> wrote:
>
> >> >> >> That sounds great. I would still want a cssDir and imagesDir in the
> >> >> >> json,
> >> >> >> so that I could simply use the last part of the relative URL marked
> >> >> >> with /*
> >> >> >> [relative-url] */ and know where the images actually were in the
> >> >> >> package.
> >> >> >> -- Yehuda
>
> >> >> >> On Sat, Oct 4, 2008 at 2:39 AM, Jörn Zaefferer
> >> >> >> <[EMAIL PROTECTED]> wrote:
>
> >> >> >>> A token that a plugin user must replace isn't acceptable, as it
> >> >> >>> defies
> >> >> >>> the drop-in nature of most plugins. But there are alternatives that
> >> >> >>> would allow Yehuda to automate replacing the relative directory URL
> >> >> >>> without anyone else having to modify the file.
>
> >> >> >>> Something like this:
> >> >> >>> background-image: url(../img/bla.png) /* [relative-url] */
>
> >> >> >>> Writing a script that looks for these inline comments and modifies
> >> >> >>> the
> >> >> >>> content accordingly wouldn't be any harder then the %imagePath%
> >> >> >>> token.
>
> >> >> >>> In any case, we should define a convention for packaging resources,
> >> >> >>> so
> >> >> >>> that a plugin author can stick with the convention, without having
> >> >> >>> to
> >> >> >>> specify the metadata. Based on that convention and inline comments
> >> >> >>> a
> >> >> >>> plugin user could automate moving resources to project-specific
> >> >> >>> folders.
>
> >> >> >>> About the other metadata.json elements:
>
> >> >> >>> How about keeping plugin names in sync with file names?
> >> >> >>> jquery.tabs.js
> >> >> >>> -> jquery.tabs; ui.core.js -> ui.core
>
> >> >> >>> What about versioned depenendencies? Dependency to a certain jQuery
> >> >> >>> version?
>
> >> >> >>> So far plugins are always packaged into a single file, something
> >> >> >>> like
> >> >> >>> utility.tabs.jquery isn't in wide use. I don't see why that should
> >> >> >>> be
> >> >> >>> changed.
>
> >> >> >>> So, to summarize:
>
> >> >> >>> {
> >> >> >>> name: "jquery.tabs",
> >> >> >>> author: "Yehuda Katz",
> >> >> >>> version: "1.0"
> >> >> >>> dependencies: {
> >> >> >>> "ui.core": "1.6",
> >> >> >>> "ui.mouse": "1.6"
> >> >> >>> }
> >> >> >>> }
>
> >> >> >>> Jörn
>
> >> >> >>> On Sat, Oct 4, 2008 at 9:49 AM, Ca-Phun Ung <[EMAIL PROTECTED]>
> >> >> >>> wrote:
> >> >> >>> > I understand what you are saying - and believe me I have much
> >> >> >>> > experience
> >> >> >>> > with "real-projects" that have their separate
> >> >> >>> > image/css/javascript
> >> >> >>> > folders
> >> >> >>> > set in a certain way. What I'm trying to impart is the idea of
> >> >> >>> > de-coupling
> >> >> >>> > so that plugin assets are independent of whatever system it is
> >> >> >>> > placed
> >> >> >>> > into.
> >> >> >>> > By adding a %imgDir% token to CSS we're already assuming
> >> >> >>> > developers
> >> >> >>> > wants to
> >> >> >>> > change CSS files whereas some might quite happily use the plugin
> >> >> >>> > as-is,
> >> >> >>> > placing it inside a dedicated plugins sub-folder and link to the
> >> >> >>> > plugin
> >> >> >>> > css
> >> >> >>> > files directly.
> >> >> >>> > The point is you don't have to map the structure implanted inside
> >> >> >>> > a
> >> >> >>> > plugin
> >> >> >>> > to the structure on your system. They could live quite happily
> >> >> >>> > together.
> >> >> >>> > What we're dealing with here is a matter of aesthetics which is
> >> >> >>> > not
> >> >> >>> > something you could get right for everyone.
> >> >> >>> > If it is absolutely essential that all images/css are placed
> >> >> >>> > inside
> >> >> >>> > that
> >> >> >>> > specified by the system then I think the automated tool could
> >> >> >>> > quite
> >> >> >>> > easily
> >> >> >>> > handle this. It should be quite simple to write a CSS parser in
> >> >> >>> > Ruby
> >> >> >>> > or
> >> >> >>> > even
> >> >> >>> > a simple regex to replace the combination found inside url(...)
> >> >> >>> > so
> >> >> >>> > it
> >> >> >>> > replaces anything before the image filename with whatever folder
> >> >> >>> > structure
> >> >> >>> > the system chooses.
> >> >> >>> > On Sat, Oct 4, 2008 at 3:10 PM, Yehuda Katz <[EMAIL PROTECTED]>
> >> >> >>> > wrote:
>
> >> >> >>> >> People who download plugins today have to go modify CSS files to
> >> >> >>> >> make
> >> >> >>> >> them
> >> >> >>> >> match their existing directory structure. I've had to contend
> >> >> >>> >> with
> >> >> >>> >> this more
> >> >> >>> >> than once with the tabs plugin, including having to figure out
> >> >> >>> >> the
> >> >> >>> >> issue in
> >> >> >>> >> the first place. Typical downloaders could use the find/replace
> >> >> >>> >> feature of
> >> >> >>> >> their editors to quickly set up the CSS the way it belongs in
> >> >> >>> >> their
> >> >> >>> >> project,
> >> >> >>> >> and we could document this, instead of developers, every time,
> >> >> >>> >> having
> >> >> >>> >> to go
> >> >> >>> >> into the bundled CSS to figure out the expectations of the
> >> >> >>> >> plugin.
> >> >> >>> >> We could potentially also set up packages.jquery.com to
> >> >> >>> >> automatically
> >> >> >>> >> replace the token for a non-tokenized version (although, again,
> >> >> >>> >> I
> >> >> >>> >> think
> >> >> >>> >> making assumptions about people's directory structures doesn't
> >> >> >>> >> map
> >> >> >>> >> well onto
> >> >> >>> >> real-world projects).
> >> >> >>> >> -- Yehuda
>
> >> >> >>> >> On Fri, Oct 3, 2008 at 9:33 PM, Ca-Phun Ung
> >> >> >>> >> <[EMAIL PROTECTED]>
> >> >> >>> >> wrote:
>
> >> >> >>> >>> A few more potential issues with the %imgDir% token are:
> >> >> >>> >>> 1. Plugin developers need to remember to add the token back in
> >> >> >>> >>> every
> >> >> >>> >>> time
> >> >> >>> >>> they package the plugin for release.
> >> >> >>> >>> 2. Those who simply download plugins without an automated tool
> >> >> >>> >>> will
> >> >> >>> >>> have
> >> >> >>> >>> a problem with this token.
> >> >> >>> >>> 3. If we're saying that this is a separate repository under
> >> >> >>> >>> packages.jquery.com, we may come into sync'ing issues as plugin
> >> >> >>> >>> developers
> >> >> >>> >>> have to upload their plugins twice. One version with the token
> >> >> >>> >>> and
> >> >> >>> >>> another
> >> >> >>> >>> without.
> >> >> >>> >>> On Sat, Oct 4, 2008 at 12:05 PM, Ca-Phun Ung
> >> >> >>> >>> <[EMAIL PROTECTED]>
> >> >> >>> >>> wrote:
>
> >> >> >>> >>>> But if we don't touch CSS and image locations we're not
> >> >> >>> >>>> assuming
> >> >> >>> >>>> anything - the plugin developer should make this decision and
> >> >> >>> >>>> not
> >> >> >>> >>>> the
> >> >> >>> >>>> automation tool. The automation tool should simply copy over
> >> >> >>> >>>> the
> >> >> >>> >>>> plugin as
> >> >> >>> >>>> is and use the metadata.json to determine what is needed for
> >> >> >>> >>>> installation.
> >> >> >>> >>>> If we start dealing with image and CSS re-location it will
> >> >> >>> >>>> make
> >> >> >>> >>>> plugin
> >> >> >>> >>>> maintenance more difficult, i.e. what happens if you decide to
> >> >> >>> >>>> delete the
> >> >> >>> >>>> plugin?
>
> >> >> >>> >>>> On Sat, Oct 4, 2008 at 4:34 AM, Yehuda Katz <[EMAIL PROTECTED]>
> >> >> >>> >>>> wrote:
>
> >> >> >>> >>>>> The problem is that you *can't* assume that the img folder
> >> >> >>> >>>>> remains
> >> >> >>> >>>>> relative to the css folder. People are putting jQuery inside
> >> >> >>> >>>>> of
> >> >> >>> >>>>> other
> >> >> >>> >>>>> directory structure (like Rails or Merb) which have their own
> >> >> >>> >>>>> conventions,
> >> >> >>> >>>>> and then it's up to the individual developer to figure out
> >> >> >>> >>>>> how
> >> >> >>> >>>>> to
> >> >> >>> >>>>> modify the
> >> >> >>> >>>>> relative paths.
> >> >> >>> >>>>> I'd like to be able to automate
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
