@jumblerg: 6 is not out yet, let's break all we need now 😉

@mynomoto: howdy! i started a new branch because i made some api changes that, if micha agrees with, may become v7; additional major changes like attribute typing, removal of jquery or moving do!, on! multimethods to different namespaces are likely to occur on this branch. i don't think anyone upgrading on 6 wants to deal with that.

@jumblerg: I was hopping that we could be more like the ember guys that add new apis and features on minor versions (also deprecating stuff) and clean up on major ones, it's an easier path to upgrades. Hoplon 6 already has namespaces changes if you have cljs files using hoplon, not sure if it would make things much worse. I'm not sure about others but I don't really want to deal with more breaking stuff on a hoplon 7 soon, I like to deal with breaking things at once...

@mynomoto: perhaps, i don't know much about how they do it, but 6 has been tagged alpha for a while, and practically speaking, there are people using it in production already.

the changes i made weren't backwards compatible

Anytime you use something tagged alpha in prod, you should be expecting breaking upgrades as you move forward, no? http://semver.org

@flyboarder: semver is not the strongest suit among clojure people. 😉

@mynomoto: maybe not but I should be able to anticipate compatibility by the version string

This is in good and bad ways. Alphas and 0.x stuff is more stable and things break in minor versions in my experience.

@flyboarder: I'm in favor of that for sure.

I would also be accepting of the ember way, and break things in minor versions, depending on what is being broken

Like name changes, I feel that is acceptable in a minor version provided the application logic remains the same

I think that if a user needs to change code to use a new version then it's breaking and should be a major version. Afaik ember only breaks things on major versions and they have deprecation warnings on the last minor in a way that if you see no deprecation warnings on your code then you can upgrade to the next major and everything should work ™️

@mynomoto: I would agree that is how things should go

As long as we are still on alpha, I'd say it is safe to include breaking changes

i think all of us try yo adhere to semantic versioning principles. v7 is just the name i gave to a branch that could someday become the foundation of a future release. i probably should have named it "pickle" or something.

@jumblerg: 'pickle' would have been a good choice 😜

maybe we merge it into 6 at some point. who knows.

@jumblerg: sorry, I don't want do discourage you to make changes, even breaking ones, I will stop complaining... 🙂

don't read too much into it. it is a branch name, not a version number.

I think this was sparked by the incredible-ness of what will be hoplonV7

no worries :)

I think I got used to hoplon 5 and the fact that things worked smoothly for a long time.

i do think that maybe we merged somethings in to master prematurely

I started getting into hoplon when only docs for 5 were available, but 6 was in alpha3 I think, I personally haven't had any breaking changes the whole way to alpha15

@flyboarder: was alpha3 already on boot2?

@mynomoto: I think so, I always used boot2

Leaning boot and hoplon at the same time was awesome, and it's the same friendly community so that helps 😄

@flyboarder: yeah, I work as a developer now and lots of what I needed to get my first job at that was @micha and @alandipert that taught me. They and this community are really amazing.

@mynomoto: and its grown! I remember the community tasks wiki used to only have a few things on it, there is page scrolling now XD

On an unrelated note, has anyone read the decentralized autonomous organization white paper?

I think this goes along with the whole API only business model, automate all the things!

oh, it took me a search to put that and DAO together, I only read about Ethereum in general, will put on my to read list among with thousands of other things 😕

But that seems interesting.

@flyboarder: I remember when there wasn't even the clojurians slack, we used to hang on irc

@mynomoto: I first poked micha on IRC, slack is much nicer :)

I think slack is too nice. It makes you stick around chatting instead of doing other things. Which is nice but I don't think it's a tool for doing work, it distracts you too much. I miss irc in this aspect, but everybody is here now...

That's actually a really good point, I am much more chatty when people all over the world are at your fingertips

re: stability i definitely agree with @mynomoto

perhaps working on a road map would be time well spent

some of the refactoring changes, like moving do! and on! into their own namespace for example

those are changes that will be very good for stability in the future

like the way clojure.string is a separate namespace, so the yhave more freedom to add to it than they would if that stuff were in clojure.core

like clojure.string/replace vs clojure.core/replace

and you don't need to use clojure.string if you don't want to

but i also feel like hoplon hasn't had many crazy changes so far

the hoplon contrib / css & asset auto-concat is the biggest change so far i think