понедельник, 14 января 2013 г., 22:14:10 UTC+2 пользователь Scott L. Burson написал: > > On Sun, Jan 13, 2013 at 4:09 AM, o_z <[email protected] <javascript:>>wrote: > >> Hi, I've compared original repository and yours. There are much >> backwards-compatible changes which IMHO could be easily merged. > > > It's true. I've only submitted pull requests for a few things I saw as > important bug fixes, but most of the other things I've done are extensions > that shouldn't interfere with existing apps. > > >> And there are some backwards-incompatible changes and some changes that I >> see as tricky or unnecessary, but that's only conclusion after code >> comparing. > > > I'm sure some of them require some discussion. Which ones do you have > questions about? > I'll tell you when we will start merging.
> > >> Some backwards-incompatible stuff (like ssl support) can be really >> important for somebody. >> So personally I need to take closer look at it (to use it in some >> project). >> > > Actually, the SSL code is backward compatible -- it has no effect unless > you specify an SSL acceptor when starting Weblocks. > > >> As for quicklisp, it is easy to use your repository for projects - load >> weblocks with quicklisp and to put your repository as >> .quicklisp/local-projects/weblocks so minimal thing to allow your >> repository testing is setup description. Not sure if there is need to >> disturb Zach. >> > > Sure, I know how to use my own version of Weblocks locally. It's only > publishing it through Quicklisp that would require Zach to do something. > > >> As for quicklisp name, "weblocks 2" is confusing name, slburson-weblocks >> or slb-weblocks or similar would be great. >> > > Well, that depends. If we agree that the new version is what we want most > people to be using in the future, then not only is "Weblocks 2" not > confusing, it expresses that intention perfectly. If we think it will > forever remain a fork that only some people will use, then it would be > better to name it something else, as you suggest. > At this time I think there will be not large code difference after merging but I can be wrong. > > >> So I suggest you to write setup instructions for your repository, to >> write main differences from original repository and announce your >> repository as recommended branch for testing on weblocks site. >> > > Before I do that, I think it would make more sense for me to go through my > changes, merging any that are backward-compatible and seem uncontroversial > into the main Weblocks repo, and writing up the rest for discussion on this > list. Once we've gone over them, we'll have a better sense of whether > we're looking at the future of Weblocks or a permanent fork. > Ok, do you have time for this ? And before merging I would like to change versioning policy for weblocks and in version x.y.z increment z on small changes/bugfixes, y on large changes. As for x, it should be zero for some indefinite time. Versioning is similar to semantic versioning (http://semver.org/ ) or what is used in asdf ( http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=summary;js=1 ) What do you think about this ? > > -- Scott > > >> воскресенье, 13 января 2013 г., 0:03:48 UTC+2 пользователь Scott L. >> Burson написал: >> >>> Hi all, >>> >>> I don't know if anyone except Brian O'Reilly has looked at my Weblocks >>> fork >>> (https://github.com/slburson/**weblocks<https://github.com/slburson/weblocks>). >>> >>> Just to remind you, it has some incompatible changes, most notably that it >>> uses Bootstrap and jQuery rather than the original Weblocks CSS and >>> JavaScript libraries. >>> >>> Although it still needs more work, I'm thinking it should become the >>> recommended version of Weblocks for new projects. How do people feel about >>> that? Of course there are existing Web apps that use the current version, >>> and we probably don't want to force everyone to convert their apps. >>> >>> So I'm thinking we should call the new version Weblocks 2, and ask Zach >>> to set up a separate Quicklisp package for it. That will allow it to >>> continue to diverge from the existing version, without inconveniencing >>> anyone who still wants to use the latter. >>> >>> Does that seem reasonable? >>> >>> An alternative would be to rename the current one to something like >>> "weblocks-stable" and let "weblocks" refer to the new one. That might be >>> appropriate if we were fairly sure that most users would eventually want to >>> use the new one. I don't think we're at that point yet. >>> >>> I'm thinking we'd maintain the two as two branches in a single repo, to >>> make it easy to copy bug fixes between them, though I'm not sure Quicklisp >>> can deal with that situation easily -- I'll ask Zach. >>> >>> What do you think? >>> >>> -- Scott >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "weblocks" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/weblocks/-/GhYR3vRFFf4J. >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/weblocks?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "weblocks" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/weblocks?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
