SBT 1.0

[etorreborre]

Quick question: what will it take for sbt to be 1.0?

Josh Suereth said on twitter that "here's two large things we wanted to fix before a 1.0. 0.13 should cover half of that"

What remains to be done then?

Thanks.

[Mark Harrah]

On Tue, 5 Mar 2013 14:53:06 -0800 (PST)
etorreborre <etorr...@gmail.com> wrote:

> Quick question: what will it take for sbt to be 1.0?

What does 1.0 mean for you?

-Mark

> Josh Suereth said on twitter that "here's two large things we wanted to fix
> before a 1.0. 0.13 should cover half of that"
>
> What remains to be done then?
>
> Thanks.
>

> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simple-build-t...@googlegroups.com.
> To post to this group, send email to simple-b...@googlegroups.com.
> Visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[etorreborre]

Good question, my definition is very fuzzy :-)

But generally it means that the "exploration phase" is over and that the most important functionalities are working ok with a more or less stable API.

E.

[Mark Harrah]

On Wed, 6 Mar 2013 18:34:31 -0800 (PST)
etorreborre <etorr...@gmail.com> wrote:

> Good question, my definition is very fuzzy :-)
>
> But generally it means that the "exploration phase" is over and that the
> most important functionalities are working ok with a more or less stable
> API.

On stability and compatibility in general: There won't be another grossly source incompatible release like 0.10. sbt has always tried to be 99% source compatible both before and after 0.10, just not 0.7->0.10. A series like 0.12.x is now binary compatible, with bugfix/improvement releases at regular 3 month intervals. Bigger, binary incompatible releases piggy-back on when Scala breaks binary compatibility, which should be 12-18 months. Those bigger releases are intended to have minimal source incompatibilities.

There is still exploration, but it is compatible. For example, the syntax changes for tasks and settings in 0.13 still support the old style and no changes should be necessary to upgrade. The new concurrentRestrictions in 0.12 support the existing configuration (parallelExecution) but are labeled experimental for the full feature.

I think there will always be areas to work on. Distributed builds seem to be the popular thing now. I'm interested to see how the various asynchronous I/O approaches (like machines) work out. The dependency management inherited from Java is inadequate*.

There isn't a conscious, clean API targeted at end users. It is "stable" in the sense that public APIs are deprecated before being removed, but not in the sense of an intentional design. I'm not sure I'm the right person to design such an API.

So, I think the process side of things (releases, compatibility) already satisfies the expectations of a 1.0 version. That to me is really what matters for 1.0, although I think an intentional API is also needed. Otherwise, I think development post-1.0 would continue the same and any line drawn for 1.0 based on features is probably arbitrary at this point. If users want 0.14 to be called 1.0, that is fine.

-Mark

* a project to propose/discuss alternatives: https://github.com/sbt/adept. (Disclaimer: I personally have no concrete plans to work on anything more than discussions at this time.)

> E.
>
> On Thursday, March 7, 2013 5:52:24 AM UTC+11, Mark Harrah wrote:
> >
> > On Tue, 5 Mar 2013 14:53:06 -0800 (PST)
> > etorreborre <etorr...@gmail.com <javascript:>> wrote:
> >
> > > Quick question: what will it take for sbt to be 1.0?
> >
> > What does 1.0 mean for you?
> >
> > -Mark
> >
> > > Josh Suereth said on twitter that "here's two large things we wanted to
> > fix
> > > before a 1.0. 0.13 should cover half of that"
> > >
> > > What remains to be done then?
> > >
> > > Thanks.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups "simple-build-tool" group.
> > > To unsubscribe from this group and stop receiving emails from it, send

> > an email to simple-build-t...@googlegroups.com <javascript:>.
> > > To post to this group, send email to simple-b...@googlegroups.com<javascript:>.

[Josh Suereth]

To echo Mark's words -

I'd like to make a concentrated effort in 0.14 to improve the Defaults.scala API for end users. 

This means everything gets a minor overhaul to make it easier for users to learn the default build, and adapt things for their use cases.

I consider this the second half of the work mark has done to improve syntax.  The goal to be to reduce sbt's "learning cliff" to a more gentle slope, and to make the intermediate build customizations more accessible.  (I.e. you shouldn't have to be able to write a full up plugin/default build yourself just to be able to understand how to add a small portion of functionality).  This combined with appealing to copy-paste build assemblers, I think we help improve the sbt experience for more users.

The second item is about dependency resolution and what we do.   Adept is one potential, but I don't see that hitting until after a 1.0 and a proper Ivy interface in SBT that allows us to extract it.

I know Hans/Gradleware has recently written their own dependency management tool, and are looking at distributed builds in the long run.   We've had a few late night chats, and I think we may be heading the same direction, albeit from different angles.  There's potential here for working together, but again, it's also about giving our users the best experience.

So, as Mark states, a 1.0 denotes a level of stability and "intentful design" that is missing in some areas of SBT.  Anyone willing to help us identify and design interfaces for 0.14, please join in.   When I find time, I'll make sure to post initial ideas and "common use cases" we need to solve for each area, before implemented an API for discussion.

I really look forward to an sbt 1.0, but I think we all agree the default build and some libraries need a cleanup before going 1.0.

[Doug Tangren]

On Thu, Mar 7, 2013 at 12:31 PM, Josh Suereth <joshua....@gmail.com> wrote:

To echo Mark's words -

I'd like to make a concentrated effort in 0.14 to improve the Defaults.scala API for end users. 

This means everything gets a minor overhaul to make it easier for users to learn the default build, and adapt things for their use cases.

I consider this the second half of the work mark has done to improve syntax.  The goal to be to reduce sbt's "learning cliff" to a more gentle slope, and to make the intermediate build customizations more accessible.  (I.e. you shouldn't have to be able to write a full up plugin/default build yourself just to be able to understand how to add a small portion of functionality).  This combined with appealing to copy-paste build assemblers, I think we help improve the sbt experience for more users.

The second item is about dependency resolution and what we do.   Adept is one potential, but I don't see that hitting until after a 1.0 and a proper Ivy interface in SBT that allows us to extract it.

not there yet https://github.com/softprops/adept/

[Mark Harrah]

On Mon, 11 Mar 2013 06:07:40 -0700 (PDT)
Fernando Racca <fra...@gmail.com> wrote:

> All of that sounds really good, in particular improving on the
> standarization of common tasks and the possibility of going for distributed
> builds.

To clarify, distributed builds are an example of something that could be explored after a 1.0. The only thing I see absolutely necessary for a 1.0 is API/common task cleanup.

-Mark

>
> Thanks!

> > On Mar 7, 2013 9:17 AM, "Mark Harrah" <dmha...@gmail.com <javascript:>>