Weblocks 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).  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

[o_z]

Hi, I've compared original repository and yours. There are much backwards-compatible changes which IMHO could be easily merged. 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. 

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). 

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.

As for quicklisp name, "weblocks 2" is confusing name, slburson-weblocks or slb-weblocks or similar would be great. As I remember it is popular practice for ruby gems to name gems like this.

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.

воскресенье, 13 января 2013 г., 0:03:48 UTC+2 пользователь Scott L. Burson написал:

[Scott L. Burson]

On Sun, Jan 13, 2013 at 4:09 AM, o_z <olex...@gmail.com> 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?
 

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. 
 

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.

-- 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).  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 webl...@googlegroups.com.
To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.

[o_z]

понедельник, 14 января 2013 г., 22:14:10 UTC+2 пользователь Scott L. Burson написал:

On Sun, Jan 13, 2013 at 4:09 AM, o_z <olex...@gmail.com> 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 ?