[zfs-fuse] 0.6.9 announced; freeze

[sgheeren]

People,

zfs-fuse 0.6.9 is coming along nicely and is expected at June 1 2010. It is a major release in many respects. See the _updated_ announcement on zfs-fuse.net:

    http://zfs-fuse.net/news/upcoming-release-1

I'll not be accepting patches to the testing branch, other than well-tested fixes until 0.6.9 is released.

In case you are wondering where I find these rules... I'm making them up as I go[1]. If you have any comments, please let us know!

Cheers,
Seth


[1] I just found out the other day I shouldn't keep pulling revisions blindly in case something subtly bad creeps in; that is why I think now is probably as good a time as any to feature-freeze the testing branch

--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

[Uwe Kubosch]

Any chance you can call this release 0.7.0 since it definitely adds function and increases the pool version?  This release is a minor version release, not a patch level release of 0.6.0.

--

With kind regards

Uwe Kubosch

Kubosch Consulting

u...@kubosch.no

http://kubosch.no/

[sgheeren]

On 05/20/2010 10:52 PM, Uwe Kubosch wrote:

Any chance you can call this release 0.7.0 since it definitely adds function and increases the pool version?  This release is a minor version release, not a patch level release of 0.6.0.

  

I can see your reasoning. But when looking at the long-term release frequency a 0.6.9 doesn't seem wrong.

I feel this version number is in the 'the die has been cast' department right now. I personally don't object to releasing a 0.7.0 in the near future (the x.x.9 was chosen in anticipation of this). But at this stage I think it is unwise to relabel the upcoming release, confusing our users and unfriendly to our (volunteer) packagers, giving more busy-work for no real difference.

In the democratic tradition of this list, I'm open to hearing opinions of others. I will point to the fact that this has been open for discussion since the 4th of May [1]

Now, I think 0.6.0 adoption has been hampered by some confusion stemming from low test coverage and an badly communicated 'hotfix' branch. Let's not do things that way this time, and deliver a solid version by any name.
Next time round, we might even get the version numbering right?

Thanks for your thoughts,
Seth

[1] http://groups.google.com/group/zfs-fuse/browse_thread/thread/abe4648b52b35474/c7e65e1a3d4d5e6c

PS. I don't fully get the logic behind the 'pool version' thing. The way I see it, pool version is independent of zfs-fuse version.
      A change of pool versions have never before lead to a new major version (afaict) in zfs-fuse. Old pools will still import nicely using 0.6.9. You might mean that people might assume they can use 0.6.0 to import any pool created with 0.6.9? I don't think many of our users will make that assumption, but even if they do: why would they have to go back? 0.6.9 is going to take over 'recommended' and 'supported' roles from 0.6.0. 0.6.9 at this point is way more stable than 0.6.x has ever been.

On May 20, 2010, at 9:29 PM, sgheeren wrote:

  

People, 

zfs-fuse 0.6.9 is coming along nicely and is expected at June 1 2010. It is a major release in many respects. See the _updated_ announcement on zfs-fuse.net:

    http://zfs-fuse.net/news/upcoming-release-1

I'll not be accepting patches to the testing branch, other than well-tested fixes until 0.6.9 is released.

In case you are wondering where I find these rules... I'm making them up as I go[1]. If you have any comments, please let us know!

Cheers,
Seth


[1] I just found out the other day I shouldn't keep pulling revisions blindly in case something subtly bad creeps in; that is why I think now is probably as good a time as any to feature-freeze the testing branch

-- 
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/
    

--
With kind regards
Uwe Kubosch
Kubosch Consulting
u...@kubosch.no
http://kubosch.no/





  

[Uwe Kubosch]

On May 20, 2010, at 11:22 PM, sgheeren wrote:

> On 05/20/2010 10:52 PM, Uwe Kubosch wrote:
>>
>> Any chance you can call this release 0.7.0 since it definitely adds function and increases the pool version? This release is a minor version release, not a patch level release of 0.6.0.
> I can see your reasoning. But when looking at the long-term release frequency a 0.6.9 doesn't seem wrong.
>
> I feel this version number is in the 'the die has been cast' department right now. I personally don't object to releasing a 0.7.0 in the near future (the x.x.9 was chosen in anticipation of this). But at this stage I think it is unwise to relabel the upcoming release, confusing our users and unfriendly to our (volunteer) packagers, giving more busy-work for no real difference.

I agree. Keep the name for clearer communication to the users.

> In the democratic tradition of this list, I'm open to hearing opinions of others. I will point to the fact that this has been open for discussion since the 4th of May [1]

I responded as quickly as I could :)

> Now, I think 0.6.0 adoption has been hampered by some confusion stemming from low test coverage and an badly communicated 'hotfix' branch. Let's not do things that way this time, and deliver a solid version by any name.
> Next time round, we might even get the version numbering right?

Yes! Woohoo!

> PS. I don't fully get the logic behind the 'pool version' thing. The way I see it, pool version is independent of zfs-fuse version.
> A change of pool versions have never before lead to a new major version (afaict) in zfs-fuse. Old pools will still import nicely using 0.6.9. You might mean that people might assume they can use 0.6.0 to import any pool created with 0.6.9? I don't think many of our users will make that assumption, but even if they do: why would they have to go back? 0.6.9 is going to take over 'recommended' and 'supported' roles from 0.6.0. 0.6.9 at this point is way more stable than 0.6.x has ever been.

The three number versioning scheme suggests that patch level releases are interchangeable both in data format and function. There are new functions in this release, and pools created with 0.6.9 cannot be used with 0.6.0. That is the reasoning :)

I only suggested a minor version bump which would suggest backwards compatibility: A pool created with 0.6.0 can be used with 0.6.9. To me, and many others I think, 0.6.9 suggest "bugfixes for 0.6.0".

As I said, I agree that keeping the 0.6.9 name is good to simplify communication with potential adopters.

Let me also say that it is absolutely GREAT that we come together and do this release! Yiiihaaaa!

[Emmanuel Anne]

2010/5/20 Uwe Kubosch <u...@kubosch.no>

I only suggested a minor version bump which would suggest backwards compatibility:  A pool created with 0.6.0 can be used with 0.6.9.  To me, and many others I think, 0.6.9 suggest "bugfixes for 0.6.0".

Yes it makes sense for me too, 0.6.9 is supposed to be a bug fix version for 0.6.0.
But now if you really want 0.6.9 instead of 0.7.0 I really have nothing against it. Version numbers have always been hard to find with zfs anyway (and the guy on the bsd list takes the pool version numbers like most people).
 

As I said, I agree that keeping the 0.6.9 name is good to simplify communication with potential adopters.

Let me also say that it is absolutely GREAT that we come together and do this release!  Yiiihaaaa!

:)
 

--
With kind regards
Uwe Kubosch
Kubosch Consulting
u...@kubosch.no
http://kubosch.no/





--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

--
zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary

[sgheeren]

By popular request:

0.6.9_beta3 has been tagged moments ago

Also, the release info has been updated, zfs-fuse.spec has been updated and the source tarball is up on the site:

http://zfs-fuse.net/releases/0.6.9